Method for characterizing and validating control software of a rail vehicle

Abstract

The invention relates to a method for characterizing and validating control software of a rail vehicle. The control software is composed of functions (FKT_1,...), wherein each function (FKT_1,...) fulfills a task assigned to it. The functions (FKT_1,...) in their totality connected to one another constitute a structure (STR) of the control software. A function-dependent checksum (HFKT_1,...) is created for each function (FKT_1,...). A structure-dependent checksum (HSTR) is created for the structure (STR). A total checksum (HGES) for the control software is created from the function-dependent checksums (HFKT_1,...) and the structure-dependent checksum (HSTR). The total checksum (HGES) characterizes and validates the approval of the control software in a certain country (EU, ZLL).

Description

[0001] The invention relates to a method for characterizing and validating control software of a rail vehicle.

[0002] Rail vehicles designed for use across countries have control software whose functional elements are inseparably interconnected and are partially structured into blocks.

[0003] The control software complies with country-specific regulations and is approved and validated for the route network of a country.

[0004] A checksum is formed by the control software. The country-specific approval is based on the checksum and ensures the validation of the control software for the country.

[0005] Different versions of the control software under consideration are produced for different country-specific regulations for the respective country.

[0006] The manufacturer of the control software wishes to use uniform, approved control software for a plurality of countries.

[0007] Starting from this, the disadvantages of the European approval procedure are explained below by way of example:

[0008] There is a risk that control software which has already been approved in the first countries of Europe must be modified as a result of objections by further countries.

[0009] If a cross-country use is planned, the modified control software loses the approval already obtained in the first countries of Europe and must be re-approved in these countries.

[0010] Furthermore, there is the danger that a country-specific differentiation is made for selected functional requirements of the control software, so that mutually contradictory approaches for the control software must be resolved in Europe.

[0011] In order to minimize or eliminate these disadvantages, it is known to provide country-specific control software in advance on the rail vehicle. When crossing a border, the relevant country-specific control software is selected and loaded into the control unit of the rail vehicle.

[0012] But this method has the following disadvantages:

[0013] - a redundant storage system for different control software or different control programs and parameters must be provided in the vehicle;

[0014] - the programs and parameters must be reloaded at the national border, where the reloading is very time-consuming due to the size of the programs;

[0015] - precautions must be taken as to whether the reloading should take place when the rail vehicle is stationary or when it is in operation during the crossing of the border;

[0016] - the question of responsibility for reloading must be clarified (e.g. whether reloading is permitted / should be done by the rail vehicle driver);

[0017] - if the authorities refuse approval, it is necessary to provide older, approved programs and parameters in advance, if necessary, in order to be able to be loaded;

[0018] - during maintenance, it must be ensured that the correct control software package is respectively entered on the redundant memory system;

[0019] - generally, a plurality of controllers is installed in the rail vehicle, so that the number of programs increases exponentially and thus the unit cost;

[0020] - finally, more expenditure must be invested in the development, management and maintenance of the programs.

[0021] In summary, the practical applicability of this approach is extremely limited.

[0022] The technical problem addressed by the present application is therefore to provide a control software for a rail vehicle which makes it easier to obtain approval and at the same time at least reduces or completely avoids the above-mentioned disadvantages.

[0023] This technical problem is solved by the features of claim 1. Advantageous extensions are given in the respective dependent claims.

[0024] In the method for characterizing and validating a control software for a rail vehicle according to the application, the control software is described by functions which are structurally connected to one another in its totality.

[0025] The functions fulfill the tasks assigned to them, and the totality of the functions connected to one another is called the structure of the control software.

[0026] A function-specific checksum is created for each function, wherein a change in the function is indicated by a change in the respective checksum.

[0027] A structure-specific checksum is created for the structure, wherein a change in the structure is indicated by a change in the structure-specific checksum.

[0028] A total checksum is formed from the function-specific checksums of the functions used and from the structure-specific checksum of the structure, which constitutes a clear fingerprint of the determined control software and is used for validation.

[0029] The approval by the authorities takes place on the basis of the total checksum.

[0030] Country-specific changes are made on selected functions and / or structures. The function-specific checksums and / or the structure-specific checksums are thereby changed and ultimately the total checksum is changed.

[0031] Thus, a country-specific change causes a change in the overall checksum, and thus a change in the overall checksum indicates a country-specific change.

[0032] The necessary subsequent approval is based on the overall checksum.

[0033] An unchanged overall checksum indicates unchanged control software, which does not need to be rechecked and approved country-specifically.

[0034] Correspondingly, a changed overall checksum indicates changed control software, which must be rechecked and approved country-specifically.

[0035] Within the framework of the detailed authentication that can be carried out on the control software, an unchanged function checksum indicates unchanged functions, which, if necessary, do not need to be rechecked for their influence on the control software.

[0036] Correspondingly, a changed function checksum indicates changed functions, which must be rechecked for their influence on the control software.

[0037] In an advantageous further development, the overall checksum, which indicates unchanged control software, is formed in the case of unchanged functions and structures of the control software.

[0038] In the case of a country-specific change in the control software, a country-specific function is formed by the selected unchanged functions by changing the functions. A country-specific overall checksum is formed by forming the country-specific function, which is different from the overall checksum of the unchanged control software.

[0039] In the case of a country-specific change in the structure of the control software, a country-specific structure is formed. A country-specific overall checksum is formed by forming the country-specific structure, which is different from the overall checksum of the unchanged control software.

[0040] In an advantageous further development, in the control software, the country-specific function or the unchanged function is activated and run by means of the country identification.

[0041] In the case of a country-specific function being activated and the structure of the control software not being changed, the country-specific overall checksum of the control software is displayed for verification.

[0042] In the case of an unchanged function being activated and the structure of the control software not being changed, the overall checksum of the unchanged control software is displayed for verification.

[0043] In an advantageous further development, the country identification is selected depending on the route network in which the rail vehicle is located or on which the rail vehicle is traveling or is driven in.

[0044] In an advantageous further development, the national identification and / or the corresponding version number of the control software is displayed to the driver of the rail vehicle for monitoring purposes, the version number being based on the overall checksum of the control software.

[0045] In an advantageous further development, in the control software, a first function provides results to an unaltered function and a country-specific function as downstream functions. Both downstream functions determine a respective result. Using the national identification acting on a selection block, only one of these results is transmitted to a further function.

[0046] In an advantageous further development, in the determination of the structure, branching points are detected in the signal flow of the control software. The connections identified by the branching points are replaced in order to calculate the checksum of the structure.

[0047] By the invention, the approval status of the control software of the rail vehicle is explicitly characterized and thus verified.

[0048] In summary, for each control software related to a route network or to a country, an overall checksum is created from the respective source code and a version number is assigned to this overall checksum. Thereby, a convincing fingerprint for the control software is formed for each country.

[0049] According to the national route network in which the rail vehicle is operated, the respective control software is activated and the respective version number of the control software is displayed to the driver of the rail vehicle for monitoring purposes.

[0050] If at this point the control software is changed for the route network of the country, for example due to a requirement of the approval authority, the part of the control software specific to this route network is supplemented or modified.

[0051] The involved, overlapping code or source code is copied and modified.

[0052] By the suitable method for creating the fingerprint, it can be shown by means of the respective checksum that all unaltered, network-specific parts of the control software have not been changed, so that the authorities that have already approved these software parts no longer need to re-approve these software parts.

[0053] By the invention, it is possible to

[0054] reduce the approval costs and risks,

[0055] shorten the so-called "Time to Market", and

[0056] easily implement network-specific customer wishes from an approval point of view.

[0057] The invention is particularly advantageous if the structure of the functions can be retained in the case of a country-specific change in the control software.

[0058] In this case a simple switching between country-specific functions can take place depending on the route network or the country. The control software itself contains the corresponding functions. Thus an upload of country-specific control software is avoided when crossing a border, only a function switching caused by the country takes place when crossing a border.

[0059] By switching the selected functions to the country-specific functions, the approval in the destination country is achieved and is displayed by the overall checksum.

[0060] At the same time the approval already obtained in other countries is retained, since the selected functions remain unchanged for these countries, so that neither the checksum of the functions involved, the checksum of the structure nor the overall checksum are changed.

[0061] The invention is explained in detail below by means of the figures. In the figures:

[0062] Figure 1 a schematic diagram showing the initial situation of the method according to the invention is shown;

[0063] Figure 2 Reference is made to Figure 1 a subsequent consideration with respect to the invention is shown;

[0064] Figure 3 Reference is made to the preceding figures to show details with respect to the method according to the invention;

[0065] Figure 4 Reference is made to Figure 3 a favourable design variant of the method according to the invention is shown; and

[0066] Figure 5 Reference is made to Figure 4 a favourable extended design of the method according to the invention is shown.

[0067] Figure 1 a schematic diagram showing the starting position with respect to the method according to the invention for the intended approval of control software for a rail vehicle is shown.

[0068] The method according to the invention is based on the fact that the control software is composed as a program of a plurality of functions FKT_1, FKT_2, FKT_3 which are structurally connected to one another.

[0069] Each function FKT_1, FKT_2, FKT_3 is assigned a task to be completed.

[0070] By each function FKT_1, FKT_2, FKT_3 a checksum is formed as a so-called "hash value", respectively, so that

[0071] - the first function FKT_1 has a first checksum HFKT_1,

[0072] - the second function FKT_2 has a second checksum HFKT_2, and

[0073] - the third function FKT_3 has a third checksum HFKT_3.

[0074] The functions FKT_1, FKT_2, FKT_3 of the control software, which are very simply shown here, are structurally connected to one another.

[0075] The connection of the functions FKT_1, FKT_2, FKT_3 to one another forms a structure STR. By means of the structure STR a checksum HSTR, which is called a hash value, is likewise formed.

[0076] For the structure STR shown here, the first function FKT_1 is connected to the third function FKT_3 directly or by means of the second function FKT_2.

[0077] The checksums of the functions HFKT_1 to HFKT_3 and the checksum of the structure HSTR form a total checksum HGES, which explicitly describes the control software and can therefore be regarded as a fingerprint of the control software.

[0078] The approval of the control software is based on the total checksum HGES.

[0079] Figure 2 Reference is made to Figure 1 A case is shown which is relevant to the further considerations of the application.

[0080] It is assumed here that the second function FKT_2 is not approved in the selected country, which is referred to below as the destination country ZLL. For example, the functionality of the second function FKT_2 which is adapted to the destination country ZLL is required within the framework of the approval in the destination country. This case is indicated by a lightning symbol at the second function FKT_2.

[0081] Figure 3 Details about the method according to the application are shown with reference to the preceding figures.

[0082] It is assumed that the first approval for Europe for the control software has been completed.

[0083] This approval is referred to below as the EU approval and is based on the total checksum HGES_EU.

[0084] But the control software is not approved in the destination country ZLL, with reference to Figure 2 which destination country requires a change to the second function FKT_2 shown there.

[0085] The total checksum HGES_EU is thus based on:

[0086] - the first checksum HFKT_1 of the first function FKT_1

[0087] - the second checksum HFKT_2EU of the second function FKT_2EU,

[0088] - the third checksum HFKT_3 of the third function FKT_3, and on

[0089] - the checksum HSTR of the structure STR.

[0090] Taking the above figures into account, the second function FKT_2EU shown here corresponds to the second function FKT_2 described in Figure 1 and Figure 2 .

[0091] The second checksum HFKT_2EU thus corresponds to the second checksum HFKT_2 described in Figure 1 and Figure 2 .

[0092] Taking the above figures into account, the total checksum HGES_EU approved by the EU corresponds to the total checksum HGES described in Figure 1 and Figure 2 .

[0093] The approval for the destination country ZLL, abbreviated below as ZLL approval, and based on the total checksum HGES_ZLL.

[0094] The total checksum HGES_ZLL is based on:

[0095] - the first checksum HFKT_1 of the first function FKT_1

[0096] - the second checksum HFKT_2ZLL of the second function FKT_2ZLL,

[0097] - the third checksum HFKT_3 of the third function FKT_3, and on

[0098] - the checksum HSTR of the structure STR.

[0099] The structure STR of the participating functions FKT_1, FKT_2ZLL, FKT_3 does not change with respect to the above figures for the destination country ZLL.

[0100] Only the second function FKT_2ZLL is adapted according to the country-specific specifications of the destination country ZLL or the specifications of the associated route network.

[0101] The second function FKT_2ZLL accordingly has a second checksum HFKT_2ZLL assigned to it.

[0102] As described above, a "hash value" or checksum is formed for each individual function:

[0103] - a first checksum HFKT_1 is formed for the first function FKT_1,

[0104] - a second checksum HFKT_2ZLL is formed for the second function FKT_2ZLL adapted to the destination country ZLL, and

[0105] - a third checksum HFKT_3 is formed for the third function FKT_3.

[0106] It is noted that the structure STR is identical for the destination country approval and the EU approval:

[0107] For the EU approval, the first function FKT_1 is connected to the third function FKT_3 directly or via the second function FKT_2EU.

[0108] For the destination country approval, the first function FKT_1 is connected to the third function FKT_3 directly or via the second function FKT_2ZLL.

[0109] The checksum HSTR formed by the structure STR is thus identical for the European countries and the destination country.

[0110] Within the framework of the EU approval, for example, which applies to all European countries but not to the destination country ZLL, the third function FKT_3 uses the result of the second function FKT_2EU if necessary, while within the framework of the destination country approval, the third function FKT_3 uses the result of the second function FKT_2ZLL.

[0111] The checksums HFKT_1, HFKT_2EU, HFKT_3 and HSTR are used for the EU approval. The overall checksum HGES_EU is composed of these checksums.

[0112] The checksums HFKT_1, HFKT_2ZLL, HFKT_3 and HSTR are used for the destination country approval. The overall checksum HGES_ZLL is composed of these checksums.

[0113] Here, the important advantages of the invention are impressively demonstrated:

[0114] If the structure STR remains unchanged, it is possible when designing the control software to switch between the country-specific functions depending on the route network or the country, here between the second functions FKT2ZLL and FKT2EU depending on the country.

[0115] The control software itself contains two functions FKT_2ZLL and FKT_2EU. Thus the uploading of country-specific control software is avoided when crossing the border, and only a function switch is carried out when crossing the border.

[0116] The destination country approval is implemented by the country-specific second function FKT_2ZLL and is indicated by the total checksum HGES_ZLL.

[0117] The EU approval is retained at the same time, since the European-approved second function FKT_2EU = FKT_2 remains unchanged, so that the total checksum HGES_EU = HGES also does not change.

[0118] Figure 4 Reference is made to Figure 3 An advantageous design variant of the method according to the application is shown.

[0119] The selection is made country-specific with respect to the respective output of the second function FKT_2EU or FKT_2ZLL.

[0120] The selection is carried out by means of a selection block MERGER.

[0121] If all upstream functions, here FKT_1, FKT_2EU and FKT_2ZLL, are calculated in parallel with reference to the selection block MERGER and the respective function results are available to the function, here FKT_3, downstream of the selection block MERGER, the selection block MERGER is used.

[0122] The selection block MERGER is controlled by means of the network identification NETZ_ID in accordance with the route network.

[0123] If the rail vehicle is located in the destination country / region, the network identification NETZ_ID = ZLL applies to the selection block MERGER.

[0124] Correspondingly, the network identification Netz_ID = EU applies to the selection block MERGER when the rail vehicle is located in a European country.

[0125] If the rail vehicle is located in the destination country ZLL, the calculation result of the second function FKT_2ZLL is connected by means of the network identification NETZ_ID = ZLL by the selection block MERGER to the third function FKT_3.

[0126] If the rail vehicle is located in a European country, the calculation result of the second function FKT_2EU is connected by means of the network identification NETZ_ID = EU by the selection block MERGER to the third function FKT_3.

[0127] In determining the structure STR, the search for the branching point is started in the selection block MERGER.

[0128] The connection identified by the branching point is replaced and the checksum HSTR of the structure is calculated.

[0129] This is achieved, for example, by determining a subnetwork located upstream of the selection block MERGER:

[0130] Subnetwork 1: FKT_1 -> FKT_2EU

[0131] Subnetwork 2: FKT_1 -> FKT_2ZLL

[0132] The two subnetworks are intersected to determine the common origin or the common intersection point.

[0133] Here, it is the first function FKT_1 which therefore must have a branching point on the output side, namely the branching point VZWP1.

[0134] The selection block MERGER itself has no influence on the structure STR, it is function-neutral and serves only for the country-specific selection of the functions, in this case the functions FKT_2EU and FKT_2ZLL.

[0135] The selection block MERGER therefore has no influence on the checksum HSTR, which is identical for the European country and the destination country.

[0136] The example of the control software shown in the aforementioned figures here is chosen and shown very simply. For complex control software, a large number of intersection points or branching points must be taken into account in determining the subnetworks, respectively, according to the signal flow, which must be determined and taken into account.

[0137] Non-identical intersection points represent different structures which will lead to a correspondingly different structure checksum.

[0138] Figure 5 Reference is made to Figure 4 An advantageous refinement of the method according to the application is shown.

[0139] Reference is made to the output of the first function FKT_1 and the input of the second functions FKT_2EU and FKT_2ZLL, between which an splitting block SPLITTER is connected.

[0140] The splitting block SPLITTER provides the result of the first function FKT_1 to both downstream functions FKT_2EU or FKT_2ZLL, which both calculate a corresponding result on the basis thereof.

[0141] The splitting block SPLITTER has no influence on the structure STR, it is function neutral, it is used only for splitting.

[0142] Therefore, the splitting block SPLITTER has no influence on the checksum HSTR, which is the same for the European country and the destination country.

[0143] In summary, in the present application, the structure regarding the functions of the control software is determined.

[0144] A checksum depending on the structure is determined or calculated as "hash value" for the structure.

[0145] The checksum depending on the structure explicitly indicates the relevant properties of the structure.

[0146] A checksum depending on the function is determined or calculated as "hash value" for each function of the control software. The checksum depending on the function explicitly indicates the content or properties of the function.

[0147] A total checksum is determined or calculated from the checksums depending on the functions and the checksum depending on the structure, which represents a unique fingerprint of the control software.

[0148] Therefore, the total checksum explicitly indicates the content or properties of the control software.

[0149] An unchanged total checksum indicates an unchanged control software, which does not have to be rechecked and does not have to be reapproved.

[0150] A changed total checksum indicates a changed control software, which has to be checked and approved.

Claims

1. A method for characterizing and validating control software of a rail vehicle, - wherein the control software is composed of functions, wherein, each function accomplishing the task assigned to it separately, - wherein the functions, in their totality of being connected to each other, constitute the structure of the control software, - wherein a function-dependent checksum is created for each function, - wherein a structure-dependent checksum is created for the structure, - wherein a total checksum for the control software is created from the function-dependent checksum and the structure-dependent checksum, - such that this total checksum is used to characterize and validate the control software against the approval of the country.

2. The method according to claim 1, - wherein the total checksum of the control software is formed which indicates that the control software has not changed, in the case that the functions and the structure of the control software have not changed, - wherein, in the case that a country-specific change has occurred in the control software, a country-specific function is constituted by the selected unchanged functions by changing the functions, - wherein a country-specific total checksum is formed by constituting the country-specific function, which is different from the total checksum of the unchanged control software.

3. The method according to claim 1, - wherein the total checksum of the control software is formed which indicates that the control software has not changed, in the case that the functions and the structure of the control software have not changed, - in the case that a country-specific change has occurred in the structure of the control software, a country-specific structure is constituted, - a country-specific total checksum is formed by constituting the country-specific structure, which is different from the total checksum of the unchanged control software.

4. The method according to claim 2, - wherein, in the control software, the country-specific function or the unchanged function is activated and run by means of a country identification, - wherein, in the case that the country-specific function is activated and the structure of the control software has not changed, the country-specific total checksum of the control software is displayed for validation, - wherein, in the case that the unchanged function is activated and the structure of the control software has not changed, the total checksum of the unchanged control software is displayed for validation.

5. The method of claim 4, wherein, The country identification is selected according to the route network in which the rail vehicle is located or into which the rail vehicle is driven.

6. The method of claim 4, wherein, The country identification and / or the corresponding version number of the control software, which is based on the total checksum of the control software, is displayed to the rail vehicle driver for monitoring.

7. The method according to claim 4, - wherein, in the control software, a first function provides results to the unchanged function and the country-specific function as downstream functions, - wherein both downstream functions determine a respective result, - but wherein, using a country identification acting on a selection block, only one of these results is transmitted to a further function.

8. The method according to claim 1, - wherein, when determining the structure, branching points are detected in the signal flow of the control software, - wherein, the connections identified by the branching points are replaced in order to calculate the checksum of the structure.

Images