ES2398998B1 - PROCEDURE AND DEVICE FOR CONTROL OF INCIDENTS IN RAILWAY TRANSPORT INFRASTRUCTURES. - Google Patents

Abstract

A set of sensors (2), related to various control systems (30), record parameters (20) of a transport network (1). # A control center (3) channels data on incidents (26) occurred in the network (1), so that the control systems (30) send to the control center (3) information about the parameters (20) analyzed, through a communications architecture (7). That data is sent to an inferences engine (4). The inference engine (4) detects incidents (26) in the transport network (1) using inference rules (5). An incident analyzer (8) determines the availability and behavior of the facilities of the transport network (1), in view of the incidents (26) detected by the inference engine (4). # When the inference engine (4) detects an incident (26) in the transport network (1), instructs a notifier (6) to send at least one notification (27) of incidence to at least one maintenance unit (11, 12) and, at least, to a work group (10), responsible for correcting the incidence (26).

Description

Procedure and device for controlling incidents in railway transport infrastructures

OBJECT OF THE INVENTION

The present invention relates to a procedure for controlling incidents and anomalies in transport infrastructures, both passenger and freight, especially in railway infrastructures, and their notification to infrastructure maintenance personnel. The control device with which the procedure is performed is also described. It is applicable in the transport industry.

TECHNICAL PROBLEM TO BE SOLVED AND BACKGROUND OF THE INVENTION

Different infrastructures are used to transport passengers and merchandise, such as the rail network and its associated control systems in rail transport. When there is an incident or anomaly in any element of the infrastructure that hinders or prevents the habitual development of traffic, the presence of people who solve the problem associated with the normal operation of the transport network is required. These people should be able to know these anomalies or incidents to correct the problems and achieve normal operation of the network in the shortest possible time. Sometimes, the human factor can stop detecting events that generate incidents and anomalies, due to stress or fatigue situations that occur in checkpoints of these networks, which are known in the state of the art. Therefore, we look for an incident control system that works autonomously without the need for human presence.

The present invention solves, among others, the following technical problems:

 Locate exactly, in time and in form, the element that has produced the fault or that is damaged in the transport network.

 It detects “online” the event or incident produced, by connecting through at least one network.

It allows to know the type of fault that has occurred before the arrival of the personnel in charge of the repair to the exact point of its location.

Notify the specialist personnel in charge of the repair more in accordance with the location and type of fault.

The unavailability times of the facilities and the transport infrastructure are reduced, which with previous control systems were high due to the delay generated in the detection of the fault and in the notification to the maintenance team in charge of the repair.

Concrete and true information about the incidence and its evolution in near-real time is obtained.

Information on the incidence and its evolution are coordinated at an ascending level within the organization that controls the infrastructure.

The present invention solves the aforementioned problems, disclosing an incident control procedure in transport infrastructures that can achieve a completely automatic way of detecting incidents. Therefore, the object of the invention is the development of a universal and integral system that allows the detection, management and analysis of railway incidents in their corresponding infrastructures through an automated and adaptive process, and their notification to the network administrator Of transport. The procedure determines the sending of messages of various types and in different ways, so that the people responsible for the maintenance of the transport network are notified. With these warnings, the teams responsible for resolving the anomalies and maintaining the transport network are made aware of the incidents in real time. This allows a quick intervention of the maintenance units to minimize the impact of the incident, and allow the network to be fully operational again in the shortest possible time.

Various methods of detecting and transmitting data in alert situations in transport networks are known in the state of the art. Thus, document EP 1456073 B1 describes an automatic transport services system in which rail traffic between two stations is carried out without a physical presence of a conductor on the trains, using various control subsystems. On the other hand, WO 2010/125321 A1 discloses a method of transferring alert data between a damaged rail vehicle and an associated control center. EP 1900597 B1 describes a railway network with sensors both in the rail and in vehicles, which allows for a fixed and mobile sensor mesh to detect incidents.

ES 2 398 998 A2

DESCRIPTION OF THE INVENTION

In order to avoid the aforementioned inconveniences and achieve the aforementioned objectives, the invention describes a procedure for controlling incidents in transport, passenger and freight infrastructures, which analyzes a series of parameters, sent by means of a signal, related to a transport network by the one that travelers and merchandise circulate interchangeably. The transport network includes:

-

a set of control sensors, which record the analyzed parameters related to the transport network;

-

primitive control systems, which agglutinate the information coming from the control sensors in some databases;

-

an infrastructure facilities control center, where the collection of data on possible incidents in the transport network is channeled;

so that a communications architecture is used with the original control systems that collect the near real-time information of the different existing sensors. Some characteristics of the procedure are:

-

the original control systems send information about the parameters analyzed to the control center, through the communications architecture;

-

The information on the parameters received at the control center is sent to an inferences engine, which is a unit that detects and analyzes incidents in near real time, and is assisted by previously defined heuristic procedures;

-

the inference engine detects incidents in the transport network using inference rules, or set of guidelines for the detection and determination of faults that affect the transport network, and that apply to different primary control systems;

-

an incident analyzer determines the availability and behavior of the facilities of the transport network, in view of the incidents detected by the inferences engine.

In this way, when the inferences engine detects an incident in the transport network, it orders an notifier to send at least one incident notification to at least one maintenance unit and at least one work group, responsible for correcting the incident.

The inference rules used by the inference engine meet at least one of the following characteristics:

a) they refer to a specific installation of a primitive control system, called simple rules;

b) they refer to at least two different installations of the same original control system, called compound rules;

c) they refer to at least two different facilities, each of them being of a different primary control system, called concatenated rules.

A signal, associated with an incident, that meets at least one inference rule becomes an inference, which is transmitted to a maintenance unit and a work group.

On the other hand, the inferences engine:

-

assigns to the inference a level of relevance (very high, high, high, medium or low) depending on the severity of the signal sent by the sensors;

-

sends the information about the inference created to a corrective maintenance unit, which returns a corporate identification code of the incident along with the identification of the work team responsible for the correction of the incident; Y,

-

sends the information received by the corrective maintenance unit to the notifier that, depending on the relevance of the inference sends:

or a) a notification to a corrective maintenance unit and a notification to the different work groups assigned, for inferences of very high, high, high, or medium level of relevance; or send:

or b) a notification to a preventive maintenance unit and a notification to the different work groups assigned, for inferences of low level of relevance.

ES 2 398 998 A2

The notifier sends the incident notification to the different work groups in hierarchical order ascending to:

-

firstly a maintenance team, so if said maintenance team does not acknowledge receipt of the notification after a certain time and after at least three notifications:

-

The notifier sends the incident notification to a monitoring team, and forwards it to the maintenance team, so that if none of the work groups acknowledges receipt of the notification after a certain time and after at least three notifications:

-

the notifier sends the notification to a technical team, and forwards it to the maintenance team and the supervision team, so that if none of the work groups acknowledges receipt of the notification after a certain time and after at least three notifications:

-

The notifier sends the notification to the address of the infrastructure network administrator, successively at different hierarchical levels, and forwards it to the maintenance team, the supervisory team, the technical team until:

or a) a response is produced by some work group, or,

or b) after a time without any response and after at least three notifications, a new notification cycle is restarted to a first maintenance team.

When a work group receives a notification from the notifier, the said work group generates an acknowledgment of receipt of said notification in the form of a reading report.

When the incident is solved, a work group sends a notification of the end of the incident to the control center notifier.

When the notifier receives the notification of the end of the incident, its data is reviewed by the corrective maintenance unit, and when the eventual closure of the incident occurs in said unit, that notification of the end of the incident is sent. Inference engine incidence.

The notifier has multimode and multimedia channels to communicate with the units and work groups.

Multimode and multimedia channels include SMS, XML, email, voice recognition systems, GSM / GPRS serial modems and communication platforms over IP.

The invention also discloses a device for controlling incidents in transport, passenger and freight infrastructures, which analyzes a series of parameters related to a transport network through which travelers and merchandise circulate interchangeably, and which uses the procedure previously described.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 represents a diagram of a transport network, which employs the incident control procedure described in the invention, together with the main elements that allow executing said procedure.

Figure 2 represents a flowchart of information during incident management.

Figure 3 represents a complete scheme of the hierarchical cyclic communication that is generated in the event of an incident in the transport network.

DESCRIPTION OF A FORM OF EMBODIMENT OF THE INVENTION

Next, the description of a preferred embodiment of the invention is made, referring to the references of the figures.

First, a list of references used is provided:

1: transport network;

2: control and maneuver sensors;

ES 2 398 998 A2

3: infrastructure facilities control center;

4: inferences engine;

5: inference rules; 5th: simple rules; 5b: compound rules; 5c: concatenated rules;

6: notifier;

7: communications architecture;

8: incident analyzer;

9: fault signal or alarm;

10: working groups; 10a: maintenance team; 10b: supervision team; 10c: technical team; 10d: management team; 10e: other hierarchical sub-levels of level 10d;

11: corrective maintenance unit;

12: preventive maintenance unit;

13: multi-mode channels;

14: multi-media channels;

15: database of a primary control system (30);

16: inferences engine database (4);

17: notifier database (6);

18: automated communications program;

19: inference;

20: parameters measured in the transport network;

21: generic control sensors of the power remote control (system 31); 21a: electric traction substations; 21b: disconnectors and neutral zones of the overhead contact line (LAC); 21c: transformer / signal reduction transformer centers;

22: interlocking security elements;

23: detectors;

24: level crossing;

25: measure of energy quality;

26: incident or event that, in general, affects the transport network (1);

27: incident or event notification; 27a: notification to maintenance units; 27b: notification to working groups;

28: reading report;

29: end of incidence notification;

30: primitive control systems;

31: power remote control;

32: remote control of signaling facilities;

ES 2 398 998 A2

33: remote control auxiliary systems and detectors;

34: level crossing concentrator;

35: power quality system.

The procedure for controlling incidents in transport, passenger and freight infrastructures, comprises various characterizing elements, which are listed below. This control is carried out in a transport network (1), particularly a railway network, which is equipped with control sensors (2) that determine the state of the transport network (1) and indicate the incidents existing in it. Other relevant elements are those cited below:

-

an infrastructure facilities control center (3), where the collection of data on possible incidents occurring in the railway infrastructure is channeled, the corresponding corrective and preventive actions are analyzed and proposed;

-

primitive control systems (30), which agglutinate the information coming from the control sensors

(2) distributed along the railway infrastructure, which have control, diagnosis and status functions on a part of the railway installation, and which, in some cases, allow the remote control of said control sensors and their remote elements ;

-

an inferences engine (4), which allows the detection of incidents or anomalies in near real time and by previously defined heuristic procedures;

-

rules of inference (5), or set of guidelines for the detection and determination of faults and events that have, or may have, impact on rail traffic and that apply to the different primary control systems (30) in a way individual, compound or concatenated;

-

a notifier (6) or device for automated communication and sending to the different specialized maintenance teams as well as to the different groups of the transport network administrator (1), which includes all the procedures related to the notification and attention to the incidents (26) of the infrastructure until its complete resolution;

-

a communications architecture (7), to communicate with all the original control systems (30), which collects the near real-time information of the different existing sensors (2);

-

an incident analyzer (8), which determines the availability and behavior of the facilities, as well as the study of the incidents that affect them.

The railway transport infrastructure comprises numerous elements necessary for the travel activity to be carried out; Some of these elements are the routes through which the railways circulate as well as the characteristic constructive elements (tunnels, viaducts, embankments, ...), the energy supply elements (transformation substations, power distribution systems, power system of electric power to vehicles (integrated by elements such as the catenary)), signaling and safety elements for traffic control and management, elements for detecting and protecting infrastructure, and the vehicles themselves that travel along the roads. This set of infrastructure elements, necessary for the travel activity to occur, will be called the transport network (1).

Said network (1) consists of control and maneuver sensors (2), of different types, which allow parameterizing the situation of the different elements that make up the transport network (1). These sensors (2), which allow the detection of anomalies and the establishment of orders, are grouped together in different primitive control systems (30). Some examples of primitive control systems (30) are the following:

a) First of all, it is worth mentioning the energy remote controls (31), which are systems that allow the reception of checks of the state of the energy transformation and distribution elements and the remote electrification system, as well as the sending of orders for remote control;

b) secondly, the remote control of railway signaling facilities (32), such as centralized traffic control, which guarantees control and management of railway traffic in safety conditions for people who use the railway as a means of transport , as well as for the people in charge of the maintenance of the railway infrastructure;

c) thirdly, the remote control of auxiliary systems and detectors (33) of railway installations, such as on-road impact detectors, hot-axis detectors, lateral impact detectors and

ES 2 398 998 A2

other complementary equipment such as technical building control equipment, superstructure control and needle heater control system;

d) the level crossing concentrators (34), which concentrate the information on the status of the elements that make up a regional and central level crossing; Y,

e) energy quality system (35), which concentrates information on energy measures to establish the characteristics of supply and consumption.

Table 1 presents some types of control sensors (2) associated with the different existing primary control systems (30).

Primal Control System (30)

Type of control sensor (2)

Electrical substations (21a)

Power Remote Control (31)

Disconnectors and neutral zones of the overhead contact line, LAC (21b)

Transformer centers / signal reducers (21c)

Remote control of railway signaling installations (32)

Interlocks (22)

Remote control auxiliary systems and detectors (33)

Detectors (23)

Level Crossing Concentrator (34)

Level Crossings (24)

Energy Quality Systems (35)

Energy Quality (25)

Table 1 - Primal control systems (30) with their associated sensor types (2).

All these sensors (2) measure and record various parameters (20) that allow to determine the state of the transport network (1). The parameters (20), which are measured and recorded by the sensors (2), are events of the different elements that manage said sensors (2). When an event responds to an anomalous position, it is an alarm or fault signal or alarm (9). This alarm signal (9) may indicate that a fault or incident (26) is occurring in said sensor (2) that registers it.

Figure 1 illustrates the procedure on which the invention is based. When a control sensor (2) [of the electrical substation type (21a), disconnectors and neutral zones of the overhead contact line, LAC (21b), transformer / signal reduction transformer centers (21c), interlock (22), detector (23), level crossings (24), or energy quality meter (25)] detects any incident or event (26), emits a fault signal (9). This signal (9) is sent to the original control system (30) on which said sensor (2) depends. Thus, for example, in the case of signals (9) referred to energy installations from electrical substations (21a), disconnectors and neutral areas of the overhead contact line, LAC (21b), or transformer / signal reduction transformer centers (21c), is sent to the power remote control type (31); in the case of signals (9) referred to signaling installations from interlocks (22), it is sent to the remote control type of signaling facilities (32); in case of signals (9) referred to detectors (23) or other auxiliary systems, it is sent to the remote control of auxiliary systems and detectors (33); in case of signals (9) referred to level crossings (24), it is sent to the level crossings concentrator (34); and in case of signals (9) referred to energy quality measurement (25), they are sent to the energy quality system (35). In turn, when the corresponding original control system (30) receives the signal (9), this signal (9) is sent to the control center (3) by means of a specific communications architecture (7), for example in XML format , where it is processed by the inferences engine (4). The reception of signals (9) between the inference engine (4) and the different primary control systems (30) of the transport network (1) is carried out by means of a data exchange with an established database model.

With these signals (9), the inference engine (4) uses inference rules (5) that allow to discern which of those signals (9), or set of signals (9), have caused an incident (26). In the event that the inference engine (4) detects that a signal (9), or set of signals, has produced a fault, the inference engine

(4)

apply the different rules of inference (5) that have been introduced. Thus, the inferences engine (4) sends the relevant data about the incident (26), such as location of the installation in the transport network (1), elements that emit the fault signals (9) and signal types of failure (9). These data are issued to the notifier

(6)

which, through a database (17) of the notifier (related to the database (16) of the inferences engine (4)), selects a workgroup (10) to which the notification will be directed, depending on of the element that emits the fault signal (9), as well as the type of fault signal (9) that it emits. This guarantees an instantaneous response and maximum reliability of the incidents (26) related to the facilities of the transport network infrastructure (1). This operating model is therefore automated, and its interpretation and transmission of the information does not depend on human factors, which allows a rapid detection of anomalies and the transmission of the same to the people and equipment that must proceed to solve them.

ES 2 398 998 A2

Figure 2 helps to understand how the information is transmitted between the different systems when an incident (26) occurs in the transport network (1). As mentioned, said transport network (1) comprises various control systems (30-35) which, in turn, have a set of sensors (2), (21-25). When an incident (26) occurs in the transport network (1), the sensors (2), (21-25) communicate with their respective control systems (30-35), exchanging information between their databases on different relevant parameters This information is transmitted through the fault or alarm signal (9), sending the appropriate parameters (20) (see also figure 1) to the control center (3). The inference engine (4) of the control center (3) analyzes the signal or set of signals (9) and, after applying specific inference rules (5), determines which of those signals comply with certain rules (5), converting the signals (9) that comply with said rules (5) into inferences (19). These inferences (19) are sent by means of a notification (27a), for example in XML format, to a corrective maintenance unit (11). Said unit (11) transmits to the notifier (6), for example in XML format, a corporate code of a maintenance team (10a), which is responsible for resolving the incident (26) that has generated the alarm signal (9 ) correspondent. Subsequently, the notifier (6) is responsible for transmitting to the maintenance team (10a), assigned to resolve the incident (26), a notification (27b), for example by SMS or email, while informing the analyzer of incidents (8). The maintenance team (10a) assigned to resolve the incident (26) sends the notifier (6) a read report (28) (for example, in XML format), so that the incident (26) that said incident is recorded Maintenance team (10a) must solve. In Figure 2, the BD reference denotes the different databases of the different elements that exchange information.

Figure 3 shows the complete scheme of hierarchical cyclic communications that are generated when an incident (26) occurs in the transport network (1). First, notification (27b) of incidence is made to a maintenance team (10a); This notification (27b) must generate an acknowledgment in the form of a reading report

(28)

by the maintenance team (10a) to which the incident resolution has been assigned (26). If the notifier (6) does not receive a reading report (28) after a set time (for example, at ten minutes), a second notification (27b) is made waiting for said reading report (28). If the notifier (6) does not receive the reading report (28), a third notification (27b) is produced (for example, at ten minutes) awaiting confirmation by the reading report (28). If after three notifications the maintenance team (10a) does not acknowledge receipt of the notification (27b), the notifier (6) starts a second escalation of notifications.

The second escalation of notifications generates a fourth notification to the maintenance team (10a). This second escalation is a notification process similar to the one seen, which includes notifications to another work group (10) higher in the hierarchy of the transport network administrator (1); This group is a supervisory team (10b). In this second climb, while the maintenance team (10a) is notified again, the corresponding supervision team (10b) is also notified waiting for a reading report (28). These notifications are repeated to both work groups (10a), (10b), up to three times, during a certain frequency (for example, every ten minutes) pending a reading report (28), as confirmation of the notification (27b) sent. If the notifier

(6)

does not receive said reading report (28) after three consecutive notifications (27b), at the fourth notification a new escalation is initiated.

The third escalation of notifications begins with the fourth notification made to the supervisory team (10b). This generates a notification process similar to those seen, now involving another higher working group (10) in the hierarchy of the transport network administrator (1); This group is a technical team (10c). This implies that, while the maintenance team (10a) and the supervision team (10b) are notified again, the corresponding technical team (10c) is also notified waiting for a reading report (28). These notifications are repeated up to three times during a certain frequency (for example, now every fifteen minutes) pending a reading report (28) by one of the working groups (10a), (10b), as confirmation of the notification (27b) sent. If the notifier (6) does not receive said reading report (28) after three consecutive notifications (27b), a new escalation is initiated at the fourth notification.

The fourth escalation of notifications begins with the fourth notification made to the technical team (10c). This fourth escalation of notifications (27b) involves notices to the address (10d) of the infrastructure network administrator (1), successively at different hierarchical levels (10e) of the address, and forwards it to the maintenance team (10a ), to the supervisory team (10b), and the corresponding technical team (10c) until: a) a response is produced that generates a reading report (28) by some work group (10a) or (10b) , or b) after a period of time without a reading report (28), a new notification cycle is started again to a first team of

ES 2 398 998 A2

maintenance (10a).

When the reading report (28) is produced at any of the levels shown, the scheme in Figure 3 is no longer valid. Therefore, said figure 3 should be understood as the communications scheme that can occur in the worst case, when a communications cycle has been completed, no reading report has been produced (28). Therefore, in the ideal operating procedure, the situation presented in Figure 3 should never occur.

After the issuance of the reading report (28), the assigned maintenance team (10a) goes to the place where the incident occurred (26). When said incident (26) has been corrected, and after the appropriate verification by the appropriate supervision team (10b), a notification of end of incident (29) is made to the notifier (6). With this notification of the end of the incident (29), the control center (3) determines, depending on the data it has, whether it can declare that the incident (26) is solved or not.

With the idea of clearly and detailed exposing the object of the invention, a detailed explanation of each of the previously mentioned elements is given below.

Infrastructure Facilities Control Center

In the known state of the art, the information relating to the infrastructure incidents of a railway transport network (1) is not regulated by a unified technical criterion. The declaration of any type of incident (26) in the network (1), as well as its description, are interpretive in nature by the personnel that receives and values them, and their temporal diffusion is variable depending on circumstantial factors.

In the present invention, all information relating to the state of the infrastructure is organized by a control center (3) of infrastructure facilities. As can be seen in figure 1, the control center (3) receives information from the different control sensors (2) of the quasi-real-time rail transport network (1), that is, the time difference between the provision of the signal (9) in a database (15) of the original system (30) and the reading of the signal (9) by the inference engine (4) is, on average, 2.5 seconds. This information refers to the status of the different facilities that make up the rail transport network (1) according to a predefined data model. Said model is processed by the inferences engine (4), which is a set of logical instructions that determine the degree of traffic impairment, the severity and type of the incidents of the rail transport network (1). According to this classification, the control center systems (3) provide information to work groups (10) in an automated way about the events occurring in the transport network (1), indicating the type, place and class of the incidence.

The work groups (10) are groups of people who are reported the anomalies produced, there are different levels of work group. These work groups refer to: 1) a first level associated with the maintenance team (10a) that must resolve the anomaly or incident detected; 2) a second level linked to the supervisors (10b) of the different maintenance teams; 3) another level (10c), higher than the previous ones, composed of technicians to whom the incidents occurred are reported, as well as the resolution of the same or the development of activities to overcome the incidence; 4) management level (10d), composed of managers, directors, and senior management, which in turn is ranked in other sub-levels (10e) in a similar way to the previous ones. In this way, the incidence (26) remains permanently controlled in all its phases until its complete resolution.

In the control center (3) all the analyzes related to the incidents (26) and alarms (9) occurred are carried out. Thus, the indicators of functionality of the facilities and technologies are characterized and evaluated, and an analysis of incidents is carried out. These analyzes allow to determine sequences and patterns that can be used for the improvement of the system rules that allow the detection of incidents (26) in the transport network (1).

Therefore, it can be noted that the control center (3) is a unit that has the following characteristics:

a) Receive information on the states and events in the network (1), where this information is subject to a specialized program of rules to determine incidents (breakdowns, failures or anomalous states that have an impact on rail traffic). This information is received in the inferences engine (4), located in the control center (3), which, after applying a series of inference rules (5), discerns between a fault affecting the transport network (1) ), a change of status or a false alarm.

b) Disseminates the notifications (27) to the work groups (10) of the organization involved in the resolution, management and knowledge of the event. These notifications (27) are made through the notifier (6), which, through a database (17), and based on a series of maintenance parameters defined by the railway network administrator (1), selects the flow of information to be disseminated and the work groups (10) that must resolve the issue (26).

ES 2 398 998 A2

c) Record all actions and activities carried out in the course of the incident (26), from the different breakdowns that make up the event to the time and personnel related to each breakdown, having the traceability of the entire process, from the record of the event or signal (9) until the fault is repaired if an intervention has been necessary. During the course of the repair of a breakdown in the transport network (1) it is necessary to monitor a series of milestones in order to make improvements in the repair and management procedure of the transport network (1). That is why different dates of arrival at the point of incidence (26), repair, commissioning of the affected installation, as well as the materials used in the repair and the personnel that, being part of the working group must be registered (10), has come to repair. All this data, through the pre-established data model, exchanges information with other management databases, to proceed with the control of personnel and material thereof.

d) Generate, modify or edit rules (5) that determine inferences (19). Due to the intrinsic characteristics of the transport network (1) and its relationship with changing elements (such as meteorology, types of railway rolling stock, types of infrastructure material, among others), the signals (9) emitted by The different elements of the control sensors (2) are variable. Therefore, the inference rules (5) must also be dynamic, depending on the location and type of the sensors (2), as well as external factors such as meteorology. That is why the control center (3) has the capacity to generate new rules (5) as well as the modification of its parameters or the adaptation to the different sensors (2).

e) Analyzes the critical indicators of availability and performance of the network facilities (1), evaluating the different technologies and functional variables of the facilities. These critical indicators of availability are necessary for the management and decision-making of the transport network administrator (1), when defining maintenance parameters of the transport network (1) and future investments in it.

Inferences engine

An inferences engine (4) is a device that allows the detection of incidents or anomalies in near real time and by previously defined heuristic procedures. Inferences (19) are defined as conclusions about events and sets of events that affect the infrastructure or its flow of circulation, obtained by deterministic or heuristic logic models; a more precise definition of inference (19) is provided in section d) of the heading "Inference rules". The inferences engine (4) reads the various data supplied by the primary control systems (30) on the signals (9) emitted by the sensors (2), processes and filters them according to predefined models and submits them to a system of rules (rules of inference (5)), which determine the existence of an incident (26), the type and degree of severity and the actions to be taken with respect to it: communications, notifications, alarm generation, records, or others.

The inferences engine (4) guarantees an instantaneous response and maximum reliability of the incidents related to the facilities of the network (1) that can be regulated. It is an automated model, without intervention or dependence on human factors of interpretation and transmission of information, in which a control sensor

(2) detects a fault signal (9) or event that, by means of a communications architecture (7) with technically defined and specified protocols, sends said information to the corresponding primary control system (30). Once this information reaches the database (15) of the original control system (30), the inferences engine (4) reads, in near-real time, said information and, applying the corresponding rules (5), certifies the existence of a fault in an element of the railway infrastructure registered in a sensor (2), as well as the type of fault. It then sends the notifier (6) true information, and without the intervention of the human factor, so that it is distributed to the corresponding working groups (10). The signal (9) provided by the sensor (2) is sent to the work group (10) without the possibility of subjective interpretation, through the inferences engine (4) and the notifier (6). Therefore, the inferences engine (4) has the following functions and characteristics:

a) The inferences engine (4) establishes a data model that allows to adapt heterogeneous data sources of the different primitive control systems (30) and that allows to be treated by the inference rules (5). This data model reflects all the characteristics necessary for the identification of the different levels of facilities that may emit a signal (9), such as 1) their identification codes in the inventory of the transport network administrator (1) , 2) its intrinsic characteristics depending on the type of element, sensor (2), installation or primary control system (30), 3) its date of manufacture and commissioning as well as the manufacturer, 4) the type of signal ( 9) that a sensor (2) can emit, 5) the coding of the type of signal (9) emitted and specified, 6) the relationship between the different elements that emit signals (9) and that are registered in the sensors (2) , 7) the parameterization of the number of elements of the same type that exist in the different levels of installations, 8) the severity of the signals (9) emitted, 9) the internal coding of the created inference, 10) the codification of the inci Provided by the transport network administrator (1), 11) the dates of transmission and reception of the signal (9) and 12) the attached graphic information that a sensor (2) can provide on the exact moment of the emission of the signal (9). This data model is versatile for all types of railway facilities depending on the needs of the control center (3), and it is a relational database model with the

ES 2 398 998 A2

databases of the different primary control systems (30) as well as with the inventory databases of the transport network administrator (1).

b) The inferences engine (4) reads the data of the different primary control systems (30) distributed along the transport network (1) in near real time, so that the event, the date, is cataloged, the category, the geographical location relative to a particular installation, the relevance and its magnitude.

c) These records are processed and subject to inference rules (5) associated with each type of event in particular. This treatment determines the declaration of an incident (26), the degree of relevance and its classification.

d) The incident (26) is transmitted through the inferences engine (4) to the corresponding units responsible for corrective maintenance (11) to register the event.

e) The notifier (6) receives an event code from the corrective maintenance unit (11), together with the reference of the work group (10) that has been assigned as responsible for attending the event.

f) With this data, the notifier (6) notifies the work groups (10) assigned to resolve the incident (26), and confirms that this request has been received.

g) The notifier (6) tracks the incident (26) and the associated faults by communicating with the agents involved in the repair of the incident (26) in each of the milestones of the procedure.

h) The notifier (6) communicates to a corrective maintenance unit (11) the closing of the event (and of all the failures that each event includes) to receive the time of commissioning of the installation and to close the incident (26 ).

i) A specialist person responsible for the event reviews all the data entered in the corrective maintenance unit (11), and when the event is permanently closed in said unit (11), this event closure information is sent and of failures to the inferences engine (4).

j) The incident (26), once closed, is recorded in the notifier (6) with all the data of the actors involved, dates of action, cause and type of event for reporting and analysis of activities.

k) The inferences engine (4) carries out queries to the notifier database (17) (6) on a continuous basis, verifying that the open incidents originating from an inference (19) have been closed or remain open. In the same control sensor (2) there cannot be two open incidents (26), so complete information about them is continuously checked. Those inferences (19) that can be generated by the inferences engine (4) with an incident already open on said sensor (2), are registered in the database (16) of the inferences engine (4) and not they are transmitted to the corrective maintenance unit (11). As already mentioned, the concept "inference" is defined in more detail in section d) associated with the "Rules of inference".

l) The inferences engine (4) has graphic tools to know in real time the status of the existing inferences (19) and the zonal distribution and imputation, functional and according to the type of installation, type of event and element causing the same.

Inference Rules

The inference rules (5) are a set of guidelines and instructions based on arithmetic-logical expressions collected in a database (16) of the inference engine (4). Depending on the type of fault signal (9) or set of signals, coming from a particular installation or control sensor (2), rules (5) have been designed such that, depending on the type of signal (9), the control sensor (2), the location of the incident and the existence or not of other associated signals (9), in a given time interval, infer that a fault is occurring in that element of the railway infrastructure registered in said sensor (2), with an impact on the transport network (1) determined according to its location.

As a practical example, a type of rule (5) is illustrated in the case of signaling installations (32). When a track circuit is occupied without the presence of a train, the interlocking (22) that controls it issues an alarm (9) of “track circuit occupation” to the facilities remote control (32), where it is registered in the database corresponding (15) to said signaling installation system (32). The inferences engine (4) reads in near real time this alarm signal (9) checking its duration. To do this the inferences engine

(4) applies a simple rule (5a) of determination of track circuit occupancy as a function of the time in which said track circuit remains occupied, that is, the time in which the signal (9) remains active, and of the location of the concrete track circuit, establishing the creation of an inference (19) with a certain relevance, depending on the duration and location. As can be deduced from this example, there are numerous rules (5) depending on the different types of primitive control systems (30) and their sensors (2).

ES 2 398 998 A2

By executing the inference rules (5), implemented in a computer, you can determine in near time those incidents (26) that affect the circulation through the transport network (1). These rules (5) are multifunctional in nature and depend on the original control system (30) treated. The rules (5) respond to intrinsic knowledge and the historical heritage of the effects in the different facilities.

As explained later in section f), these rules (5) can be simple (5a), compound (5b) or concatenated (5c). The rules (5) are specific to each type of primitive control system (30) from which the signals (9) are received. Thus, if the signals (9) come from the power remote control (31), the rules (5) will be specific for this type of installation, with a type of data relation according to the movement of the installation elements registered in the system. corresponding sensor (2). The same applies to the rules (9) from the remote control of railway signaling facilities (32), the remote control of auxiliary systems and detectors (33), the level crossing concentrator (34) and the energy quality system ( 35).

The inference rules (5) have the following functions and characteristics:

a) The inference rules (5) are collected in a database (16) of the inference engine (4), where all the received signals (9) are evaluated in real time from the different primitive systems (30).

b) The reading of the data is carried out continuously from a source data model, where the event, date, category, geographical ascription relative to a particular installation, category and its magnitude are characterized.

c) These records are processed and subject to the rules (5) associated with each type of sensor (2) or primitive system (30). This treatment determines the declaration of an incident (26), the degree of relevance and its classification.

d) The rules (5) determine a series of actions that must be performed once the alarm is detected:

-

Declaration as inference. An inference (19) is a signal (9) or event, or set of signals or events, that meet certain characteristics or rules (5) determined in a predefined time, which is understood to affect or may affect the normal development of the exploitation railway

-

Assignment of relevance level. Depending on the severity of the input signal (9) sent or the severity specified depending on the type of inference (19) created, taking into account the type of transport network (1), the location of the sensors (2) and the hourly scale, 5 levels of relevance are predefined: level 1 of relevance or level of very high impact; relevance level 2 or high impact level; relevance level 3 or high impact level; level 4 of relevance or level of medium impact, and level 5 of relevance or level of low impact. When the conditions for levels 1, 2, 3 and 4 are met, the inference (19) will be sent to the corrective maintenance unit (11), the corresponding work groups (10) will be notified, and will proceed to follow up the repair of the fault. When the inference (19) created meets the conditions of level 5 or low relevance level, it will be sent to the preventive maintenance unit (12), and an email notification will be made to the work groups (10) that are have defined for this level.

e) Depending on the relevance of the inferences (19), they will be sent to the corrective maintenance unit (11) or preventive maintenance unit (12). When the inference (19) involves a breakdown in the transport network (1), it will take relevance levels from 1 to 4, and will be sent to the corrective maintenance unit (11) for monitoring by the network administrator of transport (1), of the repair or corrective activities of the fault. When the inference (19) supposes an alert in the transport network (1) without major affectation to the infrastructure or to the traffic management, said inference (19) will be sent to the preventive maintenance unit (12), so that it is taken into account by the working group (10) responsible for the organization of the corresponding preventive maintenance work.

f) According to their influence on the facilities, the rules (5) are divided into three types: simple rules (5a), compound rules (5b) and concatenated rules (5c). Simple rules (5a) affect a specific installation of a particular type of installation. Examples of installations are: electric traction substations, interlocks, level crossings, track impact detectors, hot axis detectors, power remote controls, centralized traffic control units, auxiliary service remote controls, level crossings, quality units of energy, or others. The compound rules (5b) affect at least two different facilities of the same type (such as substation A and substation B, or interlocking A and interlocking B). The concatenated rules (5c) affect at least two different installations and of different types of installation (such as a substation and an interlocking).

g) The simple rules (5a), or the algorithms that give rise to them, can be located in a discretionary manner in the installation being monitored, or in the inferences engine itself (4).

ES 2 398 998 A2

h) The compound rules (5b) and concatenated rules (5c) are always executed in the inferences engine (4).

Notifier

 The notifier (6) is an inference engine module (4) that manages all communications with the different departments and systems of the transport network administrator (1). The notifier (6) has multi-mode channels (13) and multi-media channels (14); Examples of these types of channels are: email, SMS, XML, voice recognition systems (IVR), GSM / GPRS serial modem, communication platforms over IP, among others.

The notifier (6) presents five different ways when making communications about the incidents in the transport network (1), which are denoted as A, B, C, D and E. One of them, the A, It is completely automatic and the other four use different communication channels. The type of communication A) is automated, and is the one used by the notifier (6) to send closed and previously defined messages to the work groups (10) in the form of SMS and email, and to the corrective maintenance unit (11 ) by means of an XML message. The type of communication B) is a completely manual messaging, and is the one used for the communication of incidents of the transport network (1) when the inference engine (4) is out of service, in the form of SMS or email to work groups (10). The type of communication C) is automated and is directly dependent on the information coming from the work groups (10) that is exchanged with a voice recognition system in XML format and the notifier (6), according to previously defined messages depending on the status of the incident. The type of communication D) is the one used to exchange information with the corrective maintenance unit (11) in XML format, both from the notifier (6) to the corrective maintenance unit (11) and in reverse. The type of communication E) is of an informative type towards the senior hierarchical work groups for information on the status of breakdowns, in the form of SMS and email, with previously defined closed messages, and variables depending on the type of fault. All types of communications are coexisting, except for the type of communication B) that will only be available when for any reason the rest of the communications or the inferences engine (4) are in degraded mode.

These communications are described below in sections A) to E):

A) The notifier (6) has an automated communications program (18) to transmit the incidents (26) existing in the transport network (1). Through said automated communications program (18), the notifier

(6) carries out the following activities:

one.

Send a communication in XML format to the corrective maintenance unit (11) with the inference (19) declared in the inference engine (4) and its characterization.

2.

Send an SMS message and an email to a maintenance team (10a) assigned to the control sensor (2) located in a certain area, and verified by the corrective maintenance unit (11), previously notified by the inference engine ( 4).

3.

Confirm receipt of the sent message. If this confirmation does not occur within a scheduled time, a number of scheduled retries are made.

Four.

If after a scheduled time there is no confirmation of reading by any member of the assigned maintenance team (10a), an escalation of communications is performed notifying the members of the supervisory group (10b) related to the specialty. Simultaneously, the maintenance team is notified (10a). This is reflected in Figure 1, where the hierarchical structure represented by the pyramid shows how a notification (27b) communicates in ascending cascade to the different levels of the work groups (10).

5.

If after a programmed time there is no confirmation of reading by any member of the assigned supervisory group (10b), an ascending escalation of communications is performed notifying the members of other higher levels (10c). Simultaneously, the maintenance team (10a) and the supervisory group (10b) continue to be notified.

6.

Notification to members of other higher levels, technicians (10c) and executives (10d), is carried out progressively, establishing sub-levels (10e) within the executive level (10d), until reaching the highest hierarchy of the administrator of the transport network (1). If after a scheduled time there is no read confirmation by any member of the work groups (10), the notification escalation process stops.

7.

To stop the process at any time a confirmation of the notification is required by any of the authorized members of the different working groups (10) for the confirmation of notification. This

ES 2 398 998 A2

Confirmation is a response (reading report (28)) of the notification message (27b), made from the terminal to which the notification was issued (27b).

8.

The receipt confirmation generates an incident notification inscription and a communication is made to the organization to inform the incident status.

9.

Once the confirmation is noted, a programmed waiting time is opened so that at least one work group (10) is present at the point of incidence.

10.

If this time is exceeded, a series of periodic communications are made to the different work groups (10) reminding them of the lack of the arrival report.

eleven.

When the assigned work group (10) arrives at the point of incidence, there may be two situations:

11a) That for unknown reasons the affected facilities cannot be accessed; then the work group

(10) send a communication reflecting the time of arrival at a waiting point, and the waiting situation of activities.

11b) That you can access these facilities; Then the working group (10) will send a report of the fault situation with the damages and estimates estimated and a repair forecast.

12.

In the event that this report claims the concurrence of maintenance equipment of another specialty, the notifier (6) will communicate this situation to the corrective maintenance unit (11), so that a new work group (10) is incorporated into the chores.

13.

The corrective maintenance unit (11) will send the references of the new work group (10) to the notifier (6).

14.

The notifier (6) will start again the process of notification of the fault to the different work groups

(10) in its different hierarchies (10a, 10b, 10c, 10d, 10e).

fifteen.

If the assigned maintenance team (10a) is not person at the point of incidence in a scheduled time, a series of calls are made as described in point 10.

16.

Any breakdown that exceeds the advanced forecast time by any of the maintenance teams will initiate a new cyclic call process claiming new forecasts. The process will stop when the new forecasts materialize.

17.

When all the faults have been solved, and the transport network is available for the circulation of railway traffic, the responsible maintenance team (10a) will make a call (notification of end of incidence (29)) to the notifier (6) to inform of this situation

18.

The notifier (6) will send this communication to those parties to which, previously, the incident had been notified, either because of the relevance of the fault or because of the scalability range reached, and, in turn, will transmit the setting. in service of the installation affected by the breakdown of the corrective maintenance unit (11).

19.

The database (17) of the notifier (6) is continuously consulted by the inferences engine (4) to verify the closure or not of those incidents caused by an inference (19), and proceed to the closure of said inference (19) .

B) For the communication of incidents (26) and events that are not declared by the inferences engine (4), when it is out of service or in degraded mode, the notifier (6) uses a manual messaging program that It includes:

one.

Management of messaging channels by Email and SMS.

2.

Management of IP platform (Red Box) and GSM / GPRS modem for sending SMS messages.

3.

Creation of personalized messaging groups.

Four.

Creation of personalized messaging users.

5.

Editing groups, users and communication channels in real time.

6.

Registration of messaging activities.

7.

Multi-user and multi-profile access. Multiuser means access to the manual messaging program can be simultaneous with many users, always with prior identification in the program. Multi-profile means that the level of access to the manual messaging program varies depending on the type of profile programmed for certain users identified in the program, such as administrator profile, user profile with access to the entire territory of the transport network (1) , and user profile with access to part of the territory of the transport network (1).

ES 2 398 998 A2

C) A third form of communications is through an XML communication program through Web Service, with an automatic voice recognition (IVR) system with:

one.

Recognition of disposition reports and arrival at the point of incidence of the different maintenance teams (10a). When the maintenance team (10a) is available to repair the fault detected by the sensor (2), analyzed by the inferences engine (4) and communicated by the notifier (6), it must have a certified authorization of access to the point of incidence. This procedure must be followed for safety at work and in railway traffic. If the maintenance team (10a) does not have that authorization, it makes a call to a system with automatic voice recognition (IVR) informing of its availability but not authorization. This date of call is registered in the notifier (6) as “date of readiness for work”. When the equipment (10a) reaches the point of incidence, it makes a call to the IVR system to inform about said arrival, as well as the type of event in question, future repair needs, such as other maintenance equipment ( 10a) of another specialty and date of anticipation of commissioning of the damaged installation, and other data that may be known, such as the possible cause of the breakdown or the possible imputation thereof. These data are recorded in the notifier (6) and are sent to the corrective maintenance unit (11) associated with the corresponding event.

2.

Recognition of new repair forecasts by the different maintenance teams (10a). Once the date of arrival of the maintenance team (10a) has been registered, it may need to modify the commissioning forecast that in the previous call to the IVR system had registered, with the notifier (6) of all the modifications made in the traceability the system.

3.

Recognition of new failures for communication to the corrective maintenance unit (11). Once the date of arrival of the maintenance team (10a) has been registered, it may need more human resources of different work specialties to complete the repair of the fault, so a call is made to the IVR system, where this new one is registered need, which is sent to the notifier (6), and, after communicating to the corrective maintenance unit (11), the new maintenance team (10a) is notified that it has to go to the fault, following what is described in previous sections . This new need is registered in the notifier (6) having complete traceability of all modifications made to the system.

Four.

Recognition of definitive commissioning by the maintenance team (10a). Once the maintenance team (10a) has completed the repair of the fault, it makes a call to the IVR system where it communicates the commissioning of the installation, as well as the conditions of commissioning of the installation (traffic speed restrictions , among other). This information is transmitted to the notifier (6), where it is registered, and sent to the corrective maintenance unit (11). With the record of the date of commissioning, the notifier (6) communicates to the working groups (10) of the organization the relevant data of the incident (start date, type of event, location, cause and imputation if known, and date of commissioning) and the closing of the inference (19) by the inference engine (6).

D) A fourth form of communications is through an XML communication program through Web Service with the corrective maintenance unit (11). This form of communications is valid both for those incidents generated by the inferences engine (4), and for those incidents that can be communicated to the notifier (6) by the corrective maintenance unit (11) for monitoring and communication. The communication has:

one.

Inference opening communication (19) to the corrective maintenance unit (11).

2.

Reception and acknowledgment of opening of event from the corrective maintenance unit (11), with assignment of maintenance equipment (10a), depending on the sensor specialty (2) that originates the signal (9) analyzed for the declaration of a inference (19).

3.

In the event that the corrective maintenance unit (11) records an event that does not come directly from the inferences engine (4) (that is, when the manual opening of an inference (19) occurs), the communication has reception and event acknowledgment by the notifier (6). There is information on the specialty and type of sensor (2) and maintenance team (10a), so that the notifier (6) communicates the incident to the work groups (10).

Four.

Communication of notification time to maintenance team (10a) to the corrective maintenance unit (11).

5.

Recognition of the date of disposition and arrival of the equipment (10a) to the point of failure, for communication to the corrective maintenance unit (11).

6.

Recognition of the type of fault, probable cause of the fault and probable imputation of the fault, for communication to the corrective maintenance unit (11).

7.

Recognition of new failures for communication to the corrective maintenance unit (11).

8.

Reception and recognition of new faults from the corrective maintenance unit (11), with maintenance team assignment (10a), depending on their specialty.

9.

Recognition of definitive "commissioning" by the maintenance team (10a).

10.

Recognition of definitive information of the event from the corrective maintenance unit

ES 2 398 998 A2

(11) to the notifier (6) about type of event, cause and imputation, as well as the impact on train traffic broken down by train number, train type and minutes of delay or deletion.

E) A fifth form of communications is through an automatic messaging program via SMS and an email to communicate the status of the incident to the components of the organization group to know the following milestones:

one.

Communication of personnel in displacement.

2.

Communication of the arrival report to the “point of incidence”.

3.

Communication of reports of new forecasts.

Four.

Communication of reports of new failures.

5.

Communication of definitive "commissioning" reports.

Communication architecture The communication architecture (7), both between the original control systems (30) and the control center

(3) as among the different components that make up the center (3), it regulates and regulates the logical and hardware topology of the equipment that stores the information of the control sensors (2). This guarantees the integration, performance and degree of availability to different levels of degradation. The communication architecture (7) has, among others, the following characteristics:

a) The external query server of the primary control systems (30) is configured as a high availability cluster, and is fault tolerant. In the case of high availability, the maximum unavailability time does not exceed 2 minutes.

b) The data is updated from the original control systems (30) in near real time. This means that the time difference between the arrangement of the signal (9) in the database of the original control system (30) and the reading of the signal (9) by the inference engine (4) is, of average time , 2.5 seconds.

c) Access from the inferences engine (4) is done through an ODBC link.

d) From the inferences engine (4) only a single IP of the cluster is displayed, so the perfect synchronization of data between the different servers in the cluster must be guaranteed.

e) The power to the cluster is done redundantly, so all the elements that make up the grouping must have multiple power supplies.

f) The communication channels to the external query server of the original systems are double and redundant both from the control sensors (2) and in the connection to the network of the inference engine (4).

g) The dimensioning of the storage of the databases (15) of the primary control systems

(30) must guarantee a minimum temporary storage capacity, for example of 6 months, of all incidents (26) of the primary control systems (30).

ES 2 398 998 A2

Incident Analyzer

The incident analyzer (8) allows studies on the degree of impact and nature of the incidents in the different facilities of the transport network (1) and the most frequent causes of these. These analyzes allow classifying incidents and facilities according to their reliability, degree of exposure to factors that can determine the vulnerability of systems and technologies, and other factors. In addition, they allow to improve the systems of detection of incidents by refining the rules of inferences (5), as well as preventing the occurrence of breakdowns that may have a significant impact on the transport network (1). The incident analyzer (8) allows obtaining information related to several criteria, among others:

a) Analysis of distribution of incidents in a temporal range.

b) Analysis of the distribution of incidents by a condition criterion.

c) Analysis of distribution of incidents by type of installation.

d) Analysis of persistent incidents over time.

e) Analysis of repetitive incidents.

f) Analysis of incidents filtered by time interval.

g) Analysis of incidents by “Tag”, that is, analysis of the incidents by type of installation, by type of signal

(9) that generates the inference (19) and by type of inference rule (5).

h) Symptomatic analysis of incidents.

i) Sequential analysis of alarms, events and incidents.

j) Analysis of standard deviation of a given installation in terms of number of recorded failures.

k) Pareto analysis of unavailability times of a given installation.

l) Analysis of facilities unavailability.

m) Reliability analysis of facilities, that is, number of failures that occur in a given installation.

n) Intangibility analysis of facilities, that is, graphic analysis of the average repair time (MTTR: Mean Time To Repair), which is what happens from the moment the fault is registered until the maintenance team (10a) communicates the installation in service of the installation.

o) Analysis of the average time between failures (MTBF: Mean Time Between Failure) of the facilities.

p) Classification of facilities by number of events and types of causes.

These criteria and analysis are represented graphically in bar diagrams, sectors and trends, as well as representation in tables, with the possibility of exporting the information represented in different formats, such as xls, pdf, jpg or others, to be able to transport these analyzes to others platforms.

The incident analyzer (8) uses the data on incidents (26) and inferences (19), as well as signals

(9) and events of the different sensors (2) from which information is received, and complete information on the incidents coming from the corrective maintenance unit (11), located in the database (16) of the inference engine ( 4) and in the database (17) of the notifier (6). Applying different functions of calculation of defined parameters (MTBF, MTTR, average times, standard deviation, temporal distributions, etc.), obtains the different analyzes described above.

In view of the description made, any person skilled in the art will understand the scope of the invention and the advantages derived therefrom. The terms in which the invention has been described must be taken in a broad and non-limiting sense, the main distinguishing features of this invention being described in the following claims.

ES 2 398 998 A2

Claims (1)

1 - Incident control procedure (26) in transport, passenger and freight infrastructure, which analyzes a series of parameters (20), sent by means of a signal (9), related to a transport network (1) by which travelers and merchandise circulate interchangeably, where the transport network (1) comprises:

-

a set of control sensors (2), which record the analyzed parameters (20) related to the transport network (1);

-

primitive control systems (30), which bring together the information from the control sensors

(2) in databases (15);

-

an infrastructure facilities control center (3), where the collection of data on possible incidents in the transport network (1) is channeled;

using a communication architecture (7) with the original control systems (30) that collect the near real-time information of the different existing sensors (2), characterized in that:

-

the primary control systems (30) send information about the parameters (20) analyzed to the control center (3) by means of the communications architecture (7);

-

The information about the parameters (20) received at the control center (3) is sent to an inferences engine (4), which is a unit that detects and analyzes incidents (26) in near real time, and is assisted by procedures previously defined heuristics;

-

the inference engine (4) detects incidents (26) in the transport network (1) using inference rules (5), or set of guidelines for the detection and determination of faults affecting the transport network (1) ), and that apply to the different primitive control systems (30);

-

an incident analyzer (8) determines the availability and behavior of the facilities of the transport network (1), in view of the incidents (26) detected by the inference engine (4);

so that, when the inference engine (4) detects an incident (26) in the transport network (1), it orders a notifier (6) to send at least one notification (27) of incidence to at least a maintenance unit (11, 12) and, at least, a work group (10), responsible for correcting the incident (26). 2 - Incident control procedure (26) in a transport network (1) according to claim 1, characterized in that the inference rules (5) used by the inference engine (4) meet at least one of the following characteristics : d) refer to a specific installation of a primitive control system (30), called simple rules (5a); e) they refer to at least two different installations of the same original control system (30), called composite rules (5b); f) they refer to at least two different facilities, each of them being of a different original control system (30), called concatenated rules (5c). 3 - Incident control procedure (26) in a transport network (1) according to claim 2, characterized in that a signal (9), associated with an incident (26), which meets at least one inference rule (5) ) becomes an inference (19), which is transmitted to a maintenance unit (11, 12) and a work group (10). 4 - Incident control procedure (26) in a transport network (1) according to claim 3, characterized in that the inference engine (4):

-

assigns to the inference (19) a level of relevance (very high, high, high, medium or low) depending on the severity of the signal (9) sent by the sensors (2);

-

sends the information about the inference (19) created to a corrective maintenance unit (11), which returns a corporate identification code of the incident along with the identification of the work team (10a) responsible for the correction of the incident (26) ; Y,

-

sends the information received by the corrective maintenance unit (11) to the notifier (6) which, depending on the relevance of the inference (19) sends:

ES 2 398 998 A2

or) a notification (27a) to a corrective maintenance unit (11) and a notification (27b) to the different work groups (10) assigned, for inferences (19) of very high, high, high, or medium level of relevance; or send:

or b) a notification (27a) to a preventive maintenance unit (12) and a notification (27b) to the different work groups (10) assigned, for inferences (19) of low relevance.

5 - Incident control procedure (26) in a transport network (1) according to claim 4, characterized in that the notifier (6) sends the incident notification (27b) (26) to the different work groups (10 ) in hierarchical order ascending to:

-

firstly a maintenance team (10a), so that if said maintenance team (10a) does not acknowledge receipt of the notification (27b) after a certain time and after at least three notifications:

-

the notifier (6) sends the incident notification (27b) to a monitoring team (10b), and forwards it to the maintenance team (10a), so that if none of the working groups (10a), (10b) acknowledges receipt of the notification (27b) after a certain time and after at least three notifications:

-

the notifier (6) sends the notification (27b) to a technical team (10c), and forwards it to the maintenance team (10a) and the supervisory team (10b), so that none of the working groups (10a) ), (10b) acknowledges receipt of the notification (27b) after a certain time and after at least three notifications:

-

the notifier (6) sends the notification (27b) to the address (10d) of the infrastructure network administrator (1), successively at different hierarchical levels (10e), and forwards it to the maintenance team (10a), to the supervisory team (10b), technical team (10c) until:

or a) a response is produced by some work group (10a) or (10b), or

or b) after a time without any response and after at least three notifications, a new notification cycle is restarted to a first maintenance team (10a).

6 - Incident control procedure (26) in a transport network (1) according to claim 5 characterized in that when a work group (10) receives a notification (27b) from the notifier (6), said group of work (10) generates an acknowledgment of receipt of said notification (27b) in the form of a reading report (28). 7 - Incident control procedure (26) in a transport network (1) according to claim 6 characterized in that when the incident (26) is solved, a work group (10) sends to the notifier (6) of the center of control (3) a notification (29) of the end of the incident. 8 - Incident control procedure (26) in a transport network (1) according to claim 7 characterized in that when the notifier (6) receives the notification (29) of the end of the incident (26), the data is reviewed of the same by the corrective maintenance unit (11), and when the final closure of the incident (26) occurs in said unit (11), that notification (29) of end of the incident is sent to the engine of inferences (4). 9 - Incident control procedure (26) in a transport network (1) according to any of the preceding claims, characterized in that the notifier (6) has multimode (13) and multimedia channels (14) to communicate with the units (11, 12) and the working groups (10). 10 - Incident control procedure (26) in a transport network (1) according to claim 9, characterized in that the multimode (13) and multimedia channels (14) comprise SMS, XML, email, recognition systems voice, GSM / GPRS series modem and communication platforms over IP. 11 - Incident control device (26) in transport, passenger and freight infrastructures, which analyzes a series of parameters (20) related to a transport network (1) through which travelers and goods circulate interchangeably, characterized in that uses the method described in any of the preceding claims. ES 2 398 998 A2 ES 2 398 998 A2 ES 2 398 998 A2