Control system for a traffic network and method for preparing and / or adapting such a control system

Abstract

The invention relates to a control system (10) for a traffic network (50), which has an output interface (26) which is configured to issue outputs to the traffic network (50) during an operating phase, the outputs being able to change states of elements of the traffic network (50), also having an input interface (28) which is configured to receive inputs (28) from the traffic network (50) during the operating phase, said inputs relating to states of elements of the traffic network (50), the control system (10) comprising a knowledge base (16) which was generated during a preparation phase outside the operating phase, and the data saved in the knowledge base (16) having a data structure comprising a trio of bit switch, characteristic and action. The invention further relates to a method for preparing and / or adapting a control system.

Description

Control system for a traffic network and method for preparing and / or adapting such a control system The invention relates to a control system for a traffic network, to a method for prepar- ing / adapting such a control system and to the use of the control system and / or method. Background of the invention: Traffic network control systems are used, among other things, to set routes and con- trol signaling. For this purpose, customer specifications, according to which the con- trol is to take place, are converted into code manually or by means of generators, which code is then executed during operation. If the customer specification changes or if a new customer is acquired, new code must be created. Said code must first be validated and verified, which is extremely time-consuming. A control system for a traffic network, i.e., a traffic control system, controls the field entities of the traffic infrastructure, e.g., sets points, etc. and ensures safe traffic, e.g., flank protection. Traffic control takes place at a high safety level, preferably at SIL 4. A method for validating and verifying authorizations is known from EP3213974A1. The use of a knowledge base for conflict resolution in traffic management systems for controlling rail vehicles is also known from the prior art, for example the ARAMIS system from Thales. The knowledge base is constantly updated during operation in that solutions to conflicts that have already been resolved during operation that are deemed to be good are evaluated, and said evaluation is stored in the knowledge base to be able to resolve future conflicts better. A traffic management system takes on the strategic planning of traffic at the timetable level. Heuristic methods can be used here because traffic management works at the SIL 0 level. It has no direct ac- cess to the field entities, such as tracks, points, etc. of the traffic infrastructure. The traffic management system uses the control system to fulfill its tasks. Because traffic management systems of this type work at SIL 0, the mode of operation known there is not suitable for control systems. Therefore, such systems are not suitable as a control system. Object of the invention: It is an object of the invention to improve the safety and efficiency of a control system for a traffic network in such a way that frequent validation and verification due to changes in customer specifications are dispensed with and a very high level of safe- ty, e.g. preferably SIL 4, can be achieved. This object is achieved by a control system according to claim 1, by a method ac- cording to claim 12 and by a use according to claim 16. The dependent claims relate to advantageous further developments of the invention. Description of the invention The control system according to the invention for a traffic network has an output in- terface that is configured to issue outputs to the traffic network during an operating phase, the outputs being able to change states of entities of the traffic network. The control system also has an input interface that is configured to receive inputs from the traffic network during the operating phase, said inputs relating to states of entities of the traffic network. During the operational phase, inputs and outputs are pro- cessed by the system. Entities of a rail-bound transport network, e.g. a train system, are, e.g., field entities such as a signal, a track, a point, a level crossing, a catenary, an intersection or a train. In addition, zones, for example for construction sites or shunting, are entities of a train system. The control system according to the invention comprises a knowledge base that was created during a preparation phase of the control system outside the operating phase of the control system. The knowledge base is mapped in the form of rules, the rules comprising conditions that query flags and properties of the above-described entities of the rail-bound traffic network, as well as actions that can be performed on these entities. The data stored in the knowledge base therefore has a data structure that comprises the trio of flag, property and action. The rules, which can be present in text form, for example, are thus mapped to the above memory structures consist- ing of flags, properties and entities of the traffic network. This form allows a computer to easily and efficiently process the rules. A property represents general data, for example with integer or float as a data type. A property, for example for a signal, is the signal color (aspect), for example "red," "yellow," "green." A property for a point is, for example, the location: "left position," "right position." A flag represents binary information. A flag, for example for a point, is the locking state "yes," "no." A flag, for example for a track, is the assignment: "yes," "no." An action is an executable command. An action, for example for a point, is the "throw" movement. An action, for example for a signal, is "show aspect," for example show signal aspect "green." The knowledge base is a database having structured, machine-interpretable knowledge. The knowledge stored in the knowledge base comprises rules, sequenc- es of rules, flows and unconditional actions — this corresponds to a rule without conditions. These are also referred to as "degenerate" rules. Such actions are al- ways executed. In one embodiment of the invention, the knowledge base is structured according to an ontology. An ontology is a formally ordered representation of a set of concepts and the relationships between them. The ontology is based on data models. As a result, knowledge about the transport system can be saved and used in digitized and formal form. The ontology contains rules of inference and integrity, i.e., rules for making inferences and for ensuring their validity. The ontology thus represents knowledge as a network of information with logical relations and can thus represent complex data models. Another component of the data model can be queries. These allow the creation of loops, for example, "for each <Element> do," as well as aggregations, for example, "all <Elements> are," which can be used in the context of conditions. Aggregations are special queries used in the conditions queried by the rules to query conditions for a set of elements. During the operating phase, the knowledge base is preferably fixed, i.e., it does not change. "Fixed knowledge base" means that the knowledge base is only created or changed outside the operating phase, preferably during the preparation phase be- fore an operating phase or between different operating phases. "Outside the operat- ing phase" means that the operating phase and the preparation phase do not overlap in time, i.e., they are at different times. The knowledge base according to the inven- tion is not changed during the operating phase. This means that the behavior of the control system can be predicted deterministically and safety requirements for a safe system (SIL 4) can be easily met. The control system is therefore preferably a con- trol system for a safety-critical system (i.e., critical with regard to accident preven- tion), for example a train control system or a train protection system. A train control system is responsible for the current traffic control, and a train protection system en- sures that trains are secured, i.e., in particular, that they do not collide. This can be done, for example, by means of flank protection. If the customer specification changes or if a new customer is acquired, the knowledge base can be modified accordingly during the preparation phase. This does not change anything in the course of the operating phase, i.e., no new code has to be generated, validated and verified. The knowledge base is preferably a knowledge base that was generated from a rule base during the preparation phase. The control system is a rule-based system hav- ing a rule base from which the knowledge base is generated. The rule base is a for- malized description of rules, for example in XML, and represents the customer speci- fication. In one embodiment, the control system comprises a state database. The state data- base has possible, in particular all, states (properties) of the entities of the traffic network as a database. In one embodiment, the entities of the traffic network are assigned to one or more different domains. A domain is a problem area or an area of application within the traffic network. A train system comprises the following domains, for example: route control, signaling, indications, for example, for users such as operators or customers. The state database is preferably the same for all domains, i.e., it comprises states of all entities of all domains. In one embodiment, the control system has a condition evaluator that is designed to evaluate the conditions for one or more, preferably all, domains of the traffic network. The condition evaluator checks whether the conditions saved in the rules, which are formulated in expressions, apply. Expressions are logical expressions that can be evaluated as "true" or "false," i.e., "applicable" or "not applicable." For this purpose, the current states and the properties of the entities of the traffic system are used. This evaluation of the conditions takes place during the operating phase of the con- trol system. The condition evaluator is generic to all domains. States of entities of the traffic sys- tem are received, for example, via a governor, and evaluated, for example, in the context of a flow against given conditions. Depending on the result of the evaluation, the condition evaluator triggers actions (e.g. within the flow), which are issued via the governor as a command to the traffic network and can result in changes in the states of the entities of the traffic network. The condition evaluator reports back to the gov- ernor whether the execution of the flow was successful. The conditions are integrated in the knowledge base. They are therefore created during the preparation phase of the control system and are fixed during the operating phase. This means that the expressions evaluated in the condition evaluator do not change during the operating phase. Only the current states of the entities of the traf- fic system, which come in via the input interface of the control system, are variable. The result of the evaluation of the expressions thus changes as a function of the cur- rent states of the traffic system. The knowledge base is generated in a preparation phase that is outside, preferably before, the operating phase of the control system. Outside the preparation phase means that the operating phase and the preparation phase do not overlap in time, i.e., they are at different times. The preparation phase is used to prepare for the op- erating phase. It can be before a first operating phase or between two operating phases of the control system. If the governor encounters errors in the preparation phase during the creation of the knowledge base, for example, an unknown entity, the creation process is aborted and the error is pointed out in the rule base from which the knowledge base is to be created. In this way, the correctness and thus the consistency of the system can already be ensured in the preparation phase. This is in particular relevant to safety-critical systems, for example, SIL 4 systems. The se- lected data structure is also defined and limited in advance, such that the safety as- pect can be guaranteed even better. In one embodiment, the control system according to the invention has at least one governor. The at least one governor is configured to receive the inputs of the traffic network via the input interface and to issue the outputs to the traffic network via the output interface. The at least one governor is also configured to forward the received state of an entity of the traffic network for processing after receiving an input. The received state of the entity of the traffic network is preferably forwarded to the condi- tion evaluator for processing. The forwarding can take place, for example, via the knowledge base. Generic and domain-specific units can be provided in a governor. The generic units can be used equally for all domains. The domain-specific units are each specific to a domain. Alternatively, a separate governor specialized in the corresponding domain can be used for each domain of the traffic system. The at least one governor is configured to generate the knowledge base before the control system is put into operation. A knowledge base that relates to the respective domain of the governor can be generated for each governor. In the case of a gover- nor that has generic and domain-specific entities, the governor creates a domain- specific knowledge base for each domain. The state database is the same across all domains and for all knowledge bases and governors. All governors require factual information from the state database, for example possible positions of a point, as a basis. The time of commissioning refers to the start of the operating phase after the prepa- ration phase. By generating the knowledge base during the preparation phase, a well-defined system is made available that is known in advance and does not change during the operating phase. For example, a well-defined system does not contain contradictory conditions and / or conditions that are always "true" or always "false." By generating the knowledge base in the preparation phase and making a well-defined system available, testing is possible in advance and a high level of safe- ty can be ensured. It is thus possible, for example, to simulate operating states of the system using the system that is ready for use at this point in time, for example, using simulators that simulate the current states of the points, signals, etc. It can be veri- fied that all requirements have been implemented correctly and that nothing has been overlooked. In this way, undesired behavior of the system can be corrected very quickly. In one embodiment of the invention, the control system has a system registry data- base having executable files corresponding to the actions contained in the at least one knowledge base. The control system is preferably a train control system for a train system and is ar- ranged in a signal box. It is also applicable to systems where, for example, traffic flows must take place according to certain rules, for example in traffic control for cars or airplanes. The at least one governor and other units mentioned above or below (e.g. the condi- tion evaluator, knowledge base, rule base, etc.) are preferably in the form of software components that run on shared hardware, for example on a control computer, or on different hardware units. By dividing it into different software components, the system can quickly be adapted to other circumstances, for example other railway systems or other operators, and individual software components can be reused. The invention also relates to a method for preparing and / or adapting a control sys- tem. In the method according to the invention, a knowledge base is generated during a preparation phase of the control system outside an operating phase of the control system. The preparation phase serves to prepare for the operating phase and is therefore preferably before the operating phase of the control system. The time peri- od for creating the at least one knowledge base therefore does not overlap with the operating phase. This means that the at least one knowledge base is fixed and does not change during the operating phase. With the method according to the invention, a control system can be adapted to any customer specifications by merely structuring / modifying the knowledge base accord- ing to the customer-specific rules. All other components of the control system can continue to be used unchanged without any safety risk. New validation and verifica- tion are not necessary. The method according to the invention allows simple and secure custom configuration of the safety system. The at least one knowledge base is preferably generated from a rule base during the preparation phase. If the governor encounters errors in the preparation phase during the creation of the knowledge base, for example, an unknown entity, the creation process is aborted and the error is pointed out in the rule base from which the knowledge base is to be created. In this way, it can already be ensured during the preparation phase that the system is well defined. This is particularly relevant to safety-critical systems, for ex- ample, SIL 4 systems. The selected data structure is also defined and limited in ad- vance, such that the safety aspect can be guaranteed even better. The at least one knowledge base is preferably checked for consistency and com- pleteness during the preparation phase. The check is carried out using a state data- base. The state database comprises the possible states of the entities of the traffic network. In particular, a check is performed to determine whether the states defined by prop- erties and flags from the knowledge base are saved in the state database and the actions from the knowledge base and, if applicable, queries are saved in the system register database. In the preparation phase, a check is therefore performed to de- termine whether all actions, properties, flags and any queries in the knowledge base are available in the respective databases. This step ensures that all states for which rules are saved in the knowledge base are defined in advance. In addition, a check is performed during the preparation phase to determine whether the data saved in the knowledge base has a data structure that preferably exclusive- ly comprises the trio of flag, property and action or the quadruplet of flag, property, action and query. In a variant of the method, the condition evaluator evaluates the conditions for one or more, preferably all, domains of the traffic network. The condition evaluator is acti- vated during the execution of a flow of the knowledge base and reacts to inputs from the traffic network that relate to the states of entities of the traffic network. The control system described above and / or the method described above are advan- tageously used in a safety-critical system having a safety level of SIL 4. Further advantages of the invention can be found in the descriptions and the draw- ings. Likewise, the aforementioned features and those explained below can each be used individually or together in any desired combination. The embodiments shown and described are not to be understood as an exhaustive enumeration but rather have exemplary character for the description of the invention. In the drawings, schematically: Fig. 1 shows a control system according to the invention for a traffic network; Fig. 2 shows elements of a knowledge base of a control system according to the invention. Fig. 1 schematically shows a control system 10 for a traffic network 50. The control system 10 receives inputs from the traffic network 50 via an input interface 28. The inputs relate to states of entities of the traffic network 50, in particular the changing of states. The control system 10 issues outputs to the traffic network 50 via an output interface 26. The outputs are suitable for changing states of entities of the traffic network. A governor 12 receives the inputs of the traffic network 50 via the input interface 28. The governor 12 issues the outputs to the traffic network 50 via the output interface 26. The control system 10 can also have a plurality of governors 12 (not shown). For example, different governors 12 can be provided for different domains. However, it is also possible to cover multiple domains in one governor 12. In this case, the gover- nor 12 comprises generic (identical for all domains) and specific (domain-specific) units. The governor 12 is the central instance of the control system 10. In a preparation phase, it loads rules from a rule base 18 and generates a knowledge base 16 there- from. The rules define the conditions under which actions Ac (Fig. 2) related to the rules are carried out. Actions Ac are executable files saved in a system register da- tabase 24. The knowledge base 16 can be updated during the preparation phase via the input interface 28. During the preparation phase, the governor 12 also ensures that the actions Ac stored in the system register database 24 match the rules of the rule base 18 and the context of the control system 10. Queries Qu are also stored in the sys- tem register database 24. Queries Qu are queries to the knowledge base 16 that the governor 12 can execute. For example, a query Qu on the topology of the traffic network 50 can be performed. This allows, for example, static information to be re- quested, for example to find out a start signal of a route. Actions Ac are executed in an operating phase following the preparation phase if the associated rule "fires," i.e., the associated condition is evaluated as "true." In the op- erating phase, the governor 12 triggers a condition evaluator 14 when it is informed of the change in a state in the traffic network 50 via the input interface 28. The condi- tion evaluator 14 evaluates the state change. When a condition associated with a rule is evaluated to be "true," the rule "fires" and the associated action or actions Ac is / are executed. For example: rule when condition1 then action when condition2 then action2, action3 otherwise actionN end of rule A rule describes a condition under which an action Ac is carried out as a Boolean expression with comparison operations for the properties. The Boolean expressions relate to the states and properties of the traffic network 50. During the preparation phase and before the knowledge base 16 is created, the rules in the rule base 18 are checked for consistency to ensure that the rules are actually needed in the system and to optimize them for efficient processing. This check for consistency is preferably carried out by separate software that carries out this check automatically. It is ensured in the system register database 24 that the relationships between the rules and the actions Ac and, if applicable, queries Qu are defined, that the actions Ac and, if necessary, queries Qu are unambiguous and that the governor 12 has ac- cess to the actions Ac and, if necessary, queries Qu. The condition evaluator 14 saves the rules in an optimized form, ensures that all states checked by the rules exist in a state database 22, and optimizes the evalua- tion of the conditions of a rule. The state database 22 saves all possible states of all entities of the traffic network. State changes in the traffic network 50 can be effected, for example, by participants of the traffic network 50, i.e. by entities such as trains. Examples include a track sec- tion being occupied or exited by a train, or a point being hit by a train. State changes in the traffic network 50 can, for example, also be effected by field entities (entities in the field). Examples include a point losing monitoring, i.e., being defective in some way, or a signal being set. State changes in the traffic network 50 can, for example, also be effected by commands from an operator. Examples include an emergency stop, i.e., a signal is hard set to "red." This state change of the signal of the traffic network 50 triggers an event, which in turn leads to a reaction by the control system 10. State changes of the traffic network 50 can also be commands from the control system 10 itself. Examples include setting a route, which may lead to throwing a point. This throwing of the point, in turn, triggers events that are monitored by the control system 10. In summary, the control system 10 communicates with the traffic network 50 in that the governor 12 triggers flows F, F.1 (Fig. 2) in the knowledge base. Within the framework of flows F, F.1, rules are evaluated and the execution of actions Ac is triggered. The actions Ac in turn trigger commands to the traffic network 50. The governor 12 receives the feedback as to whether its execution was successful from the flow F, F.1. A flow F, F.1 is successful if - it was possible to evaluate all conditions successfully and - it was possible to execute all rules that fired (condition is "true”) and - it was possible to execute all actions Ac as part of the rules. The governor 12 receives a negative notification if, - for example, a condition was queried by an entity of the traffic network 50 that, for example, does not know the flags / states queried in the condition, - for example, it was not possible for an action Ac to be processed successfully by an entity of the traffic network 50. Such a negative notification can lead to a safety reaction: for example, if everything is "red," all traffic in the traffic network 50 stops. In this way, such an inconsistent state is detected and the system changes to the safe state. The control system 10 also has a user interface (not shown) by means of which a person, for example an operator, can communicate with the control system 10. The user interface can be used, for example, to set a route. A display on, for example, a screen of the user interface is the result of indication rules. The display is dependent on the state of the traffic network 50, for example a point "on the left" is calculated using rules and is shown on the display. For more complex representations, for ex- ample in the case of routes that have the state "monitored," the result of the rules is forwarded to the display via actions Ac. A command from the operator is forwarded to the control system 10 with the aid of an event. The governor 12 evaluates said event. The governor 12 can use a parser, for example an XML Parser (not shown), and a flow specifications loader (not shown), both of which are generic to all domains. The parser and the flow specifications loader are software components within the governor 12. The governor 12 uses the parser to read in the rules when creating the knowledge base 16. The governor 12 also uses the flow specifications loader to load the actions Ac and queries Qu from a system register database 20 when creating the flows F, F.1 of the knowledge base 16. Elements of the knowledge base 16 are shown schematically in Fig. 2. A flow F is a rule or a sequence of rules having associated actions Ac. A Flow F can execute the following elements: activity rule RA, activity action AcA, activity assignment AssA and activity query QuA. The rule RA activity contains Boolean expressions including comparison operations for properties that are evaluated in the condition evaluator 14. For this purpose, the condition evaluator 14 accesses the state database 22 and receives information about state changes from the governor 12. If a rule is evaluated to be "true" during the rule RA activity, one of the following activities is executed: ac- tion AcA activity, assignment AssA activity, and query QuA activity. At least one ac- tion Ac is executed during the action AcA activity. At least one query Qu is executed during the query QuA activity. Queries Qu are queries to the knowledge base 16 that the governor 12 can execute. During the assign AssA activity, a new value is as- signed to a datum of the knowledge base. An activity not shown in Fig. 2 can be a query that queries conditions for a set of entities (aggregation). Flows F.1 are structured like the flows F, i.e., rules, sequences of rules or just ac- tions Ac that are executed unconditionally. The flows F.1 are triggered by the condi- tion evaluator 14. List of reference signs control system governor condition evaluator knowledge base rule base system register database state database register database output interface input interface traffic network action query flow further flow rule activity action activity assignment activity query activity

Claims

Claims 1. A control system (10) for a traffic network (50), having an output interface (26) that is configured to issue outputs to the traffic network (50) during an operating phase, the outputs being able to change states of entities of the traffic network (50), also having an input interface (28) that is configured to receive inputs (28) from the traffic network (50) during the operating phase, said inputs relating to states of entities of the traffic network (50), the control system (10) comprising a knowledge base (16) that was generated during a preparation phase outside the operating phase, and the data saved in the knowledge base (16) having a data structure comprising a trio of flag, prop- erty and action.

2. The control system according to claim 1, characterized in that the knowledge base (16) is fixed during the operating phase.

3. The control system according to claim 1 or 2, characterized in that the knowledge base (16) was generated from a rule base (18) during the prepara- tion phase.

4. The control system according to any of the preceding claims, characterized in that the control system (10) has at least one state database (22) comprising possible states of the entities of the traffic network (50).

5. The control system according to claim 4, characterized in that the entities of the traffic network (50) are assigned to one or more different domains.

6. The control system according to claim 5, characterized in that it has a condition evaluation component (14) that is designed to evaluate the conditions for one or more, preferably all, domains of the traffic network (50). / . The control system according to any of the preceding claims, characterized in that it has at least one central unit (12) that is configured to receive the inputs of the traffic network via the input interface (28) and to issue the outputs to the traffic network via the output interface (26), the at least one central unit (12) al- so being configured to forward the input to the knowledge base (16) after re- ceiving an input from the traffic network (50).

8. The control system according to claim 7 and 5, characterized in that a central unit (12) is provided for each domain.

9. The control system according to claim 7 or 8, characterized in that the at least one central unit (12) is configured to generate the state database (22) before the control system (10) is put into operation.

10. The control system according to any of the preceding claims, characterized in that the control system (10) comprises a system register database (20) having executable files corresponding to the actions (Ac) contained in the knowledge base (16).

11. The control system according to any of the preceding claims, characterized in that the control system is a train control system and is arranged in particular in a signal box.

12. A method for preparing and / or adapting a control system (10) according to any of the preceding claims, characterized in that a knowledge base (16) is gener- ated during a preparation phase of the control system outside an operating phase of the control system.

13. The method according to claim 12, characterized in that the knowledge base (16) is generated from a rule base (18).

14. The method according to claim 12 or 13, characterized by the step that the knowledge base (16) is checked for consistency and completeness during the preparation phase, the check being carried out using a state database (22), the state database (22) comprising possible states of the entities of the traffic net- work (50).

15. The method according to claim 14, characterized in that the condition evalua- tion component (14) evaluates the conditions for one or more, preferably all, domains of the traffic network (50).

16. Use of a method according to any of claims 12 to 15 and / or a control system according to any of claims 1 to 11 in a safety-critical system having a safety level of at least SIL 4.

Images