METHOD FOR IDENTIFYING AND VERIFYING CONTROL SOFTWARE OF A RAIL VEHICLE

Abstract

A method identifies and verifies control software of a rail vehicle. In the method, the control software is formed by functions, with each function fulfilling an associated task. As a networked collective, the functions form the structure of the control program. A function-dependent checksum is generated for each function. A structure-dependent checksum is generated for the structure. A total checksum is generated for the control software from the function-dependent checksums and the structure-dependent checksum. This total checksum identifies and verifies the control software for homologation in a country.

Claims

1-8. (canceled)

9. A method for identifying and verifying control software of a rail vehicle, wherein the control software is formed by functions, wherein each function of the functions performs a task respectively assigned thereto, in which the functions, in their interconnected entirety, form a structure of the control software, which comprises the steps of: creating a function-dependent checksum for each of the functions resulting in a plurality of function-dependent checksums; creating a structure-dependent checksum for the structure; and creating an overall checksum for the control software from the function-dependent checksums and from the structure-dependent checksum, wherein the overall checksum identifies and verifies the control software for authorization in a country.

10. The method according to claim 9, wherein: in a case of unchanged functions, and in a case of an unchanged structure of the control software, forming the overall checksum to indicate unchanged control software; and in a case of a change to the control software for country-specific reasons, forming a country-specific function from a chosen unchanged function by changing the function, wherein the forming of the country-specific function forms a country-specific overall checksum that differs from the overall checksum of the unchanged control software.

11. The method according to claim 9, wherein: in a case of unchanged functions and an unchanged structure of the control software, the overall checksum is formed and indicates unchanged control software; and in a case of a change to the structure of the control software for country-specific reasons, forming a country-specific structure, wherein the forming of the country-specific structure forms a country-specific overall checksum that differs from the overall checksum of the unchanged control software.

12. The method according to claim 10, wherein: in which either the country-specific function or the unchanged function is activated and operated in the control software with an aid of a country identifier; in which, in a case of an activated country-specific function and in the case of the unchanged structure of the control software, the country-specific overall checksum of the control software is displayed for verification; in which, in a case of an activated unchanged function and in a case of the unchanged structure of the control software, the overall checksum of the unchanged control software is displayed for verification.

13. The method according to claim 12, which further comprises selecting the country identifier on a basis of a rail network in which the rail vehicle is located or into which the rail vehicle is traveling.

14. The method according to claim 12, which further comprises displaying the country identifier and/or a corresponding version number of the control software, which is based on the overall checksum of the control software, to a rail vehicle driver for monitoring purposes.

15. The method according to claim 12, wherein in the control software, a first function supplies both the unchanged function and the country-specific function, as downstream functions, with results, in which two said downstream functions ascertain respective results, in which, using the country identifier, which acts on a selection block, only one of the results is however transmitted to a further function.

16. The method according to claim 9, wherein when ascertaining the structure, detecting branching points in a signal profile of the control software, and in which connections identified by way of the branching points are substituted in order to calculate the checksum of the structure.

Description

[0062] The invention is explained in more detail below with reference to a drawing, in which:

[0063] FIG. 1 shows a basic illustration of a starting situation for the method according to the invention,

[0064] FIG. 2 shows, with reference to FIG. 1, a situation for subsequent considerations regarding the invention,

[0065] FIG. 3 shows, with reference to the previous figures, details regarding the method according to the invention,

[0066] FIG. 4 shows, with reference to FIG. 3, an advantageous refinement of the method according to the invention, and

[0067] FIG. 5 shows, with reference to FIG. 4, an advantageous development of the method according to the invention.

[0068] FIG. 1 shows a basic illustration of a starting situation for the method according to the invention for an intended authorization of control software of a rail vehicle.

[0069] The method according to the invention is based on the fact that the control software is formed as a program by a number of structurally interconnected functions FKT_1, FKT_2, FKT_3.

[0070] Each function FKT_1, FKT_2, FKT_3 is assigned a task to be performed.

[0071] A respective checksum is formed by way each function FKT_1, FKT_2, FKT_3 in the form of what is known as a “hash”, such that [0072] a first function FKT_1 has a first checksum HFKT_1, [0073] a second function FKT_2 has a second checksum HFKT_2, and [0074] a third function FKT_3 has a third checksum HFKT_3.

[0075] The functions FKT_1, FKT_2, FKT_3 of the control software, illustrated here in highly simplified form, are structurally interconnected with one another.

[0076] The interconnection of the functions FKT_1, FKT_2, FKT_3 forms a structure STR. A checksum HSTR, referred to as a hash, is likewise formed by way of this structure STR.

[0077] In the case of the structure STR shown here, the first function FKT_1 is linked to the third function FKT_3 either directly or via the second function FKT_2.

[0078] An overall checksum HGES is formed from the checksums of the functions HFKT_1 to HFKT_3 and from the checksum of the structure HSTR and uniquely describes the control software, and may thus be considered to be its fingerprint.

[0079] The control software is authorized based on the overall checksum HGES.

[0080] FIG. 2 shows, with reference to FIG. 1, a situation for subsequent considerations regarding the invention.

[0081] It is assumed here that authorization is not given for the second function FKT_2 in a selected country, which is referred to hereinafter as destination country ZLL.

[0082] By way of example, in the context of the destination country authorization, a functionality of the second function FKT_2 that is adapted to the destination country ZLL is required. This situation is illustrated by a lightning symbol on the second function FKT_2.

[0083] FIG. 3 shows, with reference to the previous figures, details regarding the method according to the invention.

[0084] It is assumed that a first authorization for Europe has been performed for the control software.

[0085] This authorization, which is referred to hereinafter as EU authorization, is based on an overall checksum HGES_EU.

[0086] The control software is however not authorized in the destination country ZLL, which requires, with reference to FIG. 2, a change to the second function FKT_2 illustrated in said figure.

[0087] The overall checksum HGES EU is thus based on: [0088] the first checksum HFKT_1 of the first function FKT_1, [0089] a second checksum HFKT_2 EU of a second function FKT_2 EU, [0090] the third checksum HFKT_3 of the third function FKT_3, and on [0091] the checksum HSTR of the structure STR.

[0092] With regard to the previous figures, the second function FKT_2 EU shown here corresponds to the second function FKT_2 described in FIG. 1 and FIG. 2.

[0093] The second checksum HFKT_2 EU thus corresponds to the second checksum HFKT_2 described in FIG. 1 and FIG. 2.

[0094] With regard to the previous figures, the overall checksum HGES_EU for the EU authorization thus corresponds to the overall checksum HGES described in FIG. 1 and FIG. 2.

[0095] The authorization for the destination country ZLL, which is referred to hereinafter as ZLL authorization, is based on an overall checksum HGES_ZLL.

[0096] The overall checksum HGES_ZLL is based on: [0097] the first checksum HFKT_1 of the first function FKT_1, [0098] a second checksum HFKT_2 ZLL of a second function FKT_2 ZLL, [0099] the third checksum HFKT_3 of the third function FKT_3, and based on [0100] the checksum HSTR of the structure STR.

[0101] For the destination country ZLL, the structure STR of the functions FKT_1, FKT_2 ZLL, FKT_3 involved is unchanged with regard to the previous figures.

[0102] Only the second function FKT_2 ZLL is adapted to country-specific rules of the destination country ZLL or to rules of the associated rail network.

[0103] The second function FKT_2 ZLL accordingly has a checksum HFKT_2 ZLL that is assigned thereto.

[0104] As described above, “hashes” or checksums are formed for the individual functions: [0105] the first checksum HFKT_1 for the first function FKT_1, [0106] the second checksum HFKT_2 ZLL for the second function FKT_2 ZLL adapted to the destination country ZLL, [0107] the third checksum HFKT_3 for the third function FKT_3.

[0108] It should be noted that the structure STR for the destination country authorization and for EU authorization is the same:

[0109] For the EU authorization, the first function FKT_1 is linked to the third function FKT_3 either directly or via the second function FKT_2 EU.

[0110] For the destination country authorization, the first function FKT_1 is linked to the third function FKT_3 either directly or via the second function FKT_2 ZLL.

[0111] The checksum HSTR formed by way of the structure STR is thus identical for the countries in Europe and for the destination country.

[0112] In the context of the EU authorization, which applies for example for all countries in Europe but not for the destination country ZLL, the third function FKT_3 thus, when necessary, uses results from the second function FKT_2 EU, while, in the context of the destination country authorization, the third function FKT_3 uses results from the second function FKT_2 ZLL.

[0113] For the EU authorization, the checksums HFKT_1, HFKT_2 EU, HFKT_3 and HSTR are used. The overall checksum HGES_EU is formed from these checksums.

[0114] For the destination country authorization, the checksums HFKT_1, HFKT_2 ZLL, HFKT_3 and HSTR are used. An overall checksum HGES ZLL is formed from these checksums.

[0115] One essential advantage of the present invention has an impressive effect here:

[0116] With the structure STR staying the same, when developing the control software, it is possible to change over between country-specific functions depending on rail networks or countries—here between the functions FKT_2 ZLL and FKT_2 EU depending on the country.

[0117] The control software itself contains both functions FKT_2 ZLL and FKT_2 EU. When crossing a border, uploading of country-specific control software is thus avoided; only a functional changeover takes place when crossing the border.

[0118] The country-specific second function FKT_2 ZLL means that the destination country authorization is achieved and indicated by way of the overall checksum HGES_ZLL.

[0119] At the same time, the EU authorization is maintained, since its second function FKT_2 EU =FKT_2 remains unchanged, meaning that the overall checksum HGES_EU=HGES does not change either.

[0120] FIG. 4 shows, with reference to FIG. 3, an advantageous refinement of the method according to the invention.

[0121] With regard to the respective output of the second function FKT_2 EU or FKT_2 ZLL, a selection is made in a country-specific manner.

[0122] This selection is made by a selection block MERGER.

[0123] The selection block MERGER is used when, with regard to the selection block MERGER, all upstream functions, that is to say here FKT_1, FKT_2 EU and FKT_2 ZLL, were calculated in parallel and respective function results for a function downstream of the selection block MERGER, here FKT_3, are available for selection.

[0124] The selection block MERGER is controlled by way of a country identifier Netz_ID depending on the rail network.

[0125] For the selection block MERGER, a country identifier is Netz_ID=ZLL when the rail vehicle is located in the destination country.

[0126] Accordingly, a country identifier for the selection block MERGER is Netz_ID=EU when the rail vehicle is located in the countries in Europe.

[0127] If the rail vehicle is located in the destination country ZLL, the calculated results from the second function FKT_2 ZLL are switched through to the third function FKT_3 by the selection block MERGER using the network identifier Netz_ID=ZLL.

[0128] If the rail vehicle is located in the countries in Europe, the calculated results from the second function FKT_2 EU are switched through to the third function FKT_3 by the selection block MERGER using the network identifier Netz_ID=EU.

[0129] When ascertaining the structure STR, branching points thus begin to be sought in the selection block MERGER.

[0130] Connections identified by way of branching points are substituted and a checksum of the structure HSTR is calculated.

[0131] This is achieved for example by ascertaining subnetworks that are located upstream of the selection block MERGER: [0132] Subnetwork 1: FKT_1.fwdarw.FKT_2 EU [0133] Subnetwork 2: FKT_1.fwdarw.FKT_2 ZLL

[0134] These two subnetworks are intersected in order to ascertain a common origin or a common point of intersection.

[0135] This is the first function FKT_1 here, which must thus have a branching point, namely the branching point VZWP1, on the output side.

[0136] The selection block MERGER itself has no influence on the structure STR; it has a neutral function and is used only for the country-specific selection of functions, here of the functions FKT_2 EU and FKT_2 ZLL.

[0137] The selection block MERGER thus has no influence on the checksum HSTR, which is identical both for the countries in Europe and for the destination country.

[0138] The example, shown here in the above figures, of control software is selected and illustrated in a highly simplified manner. In the case of complex control software, depending on the signal flow when ascertaining subnetworks, a multiplicity of points of intersection or branching points should be expected, and these have to be ascertained and taken into consideration.

[0139] Non-identical points of intersection indicate different structures that would lead to accordingly different structure checksums.

[0140] FIG. 5 shows, with reference to FIG. 4, an advantageous development of the method according to the invention.

[0141] With regard to the output of the first function FKT_1 and the inputs of the second functions FKT_2 EU and FKT_2 ZLL, a splitter block SPLITTER is interposed.

[0142] The splitter block SPLITTER provides results from the first function FKT_1 to both of the downstream functions FKT_2 EU and FKT_2 ZLL, which both calculate respective results based thereon.

[0143] The splitter block SPLITTER has no influence on the structure STR; it has a neutral function and is used only for splitting.

[0144] The splitter block SPLITTER thus also has no influence on the checksum HSTR, which is identical both for the countries in Europe and for the destination country.

[0145] In summary, in the invention, with regard to the control software, a structure for its interconnected functions is ascertained.

[0146] A structure-dependent checksum is ascertained or calculated for the structure in the form of a “hash”.

[0147] The structure-dependent checksum clearly indicates an associated property of the structure.

[0148] A function-dependent checksum is ascertained or calculated for each function of the control software in the form of a “hash”. The function-dependent checksum clearly indicates content or a property of the function.

[0149] An overall checksum is ascertained or calculated from the function-dependent checksums and from the structure-dependent checksum and constitutes a unique fingerprint for the control software.

[0150] The overall checksum thus clearly indicates content or a property of the control software.

[0151] An unchanged overall checksum indicates unchanged control software that does not have to be checked again and does not have to be authorized again.

[0152] A changed overall checksum indicates changed control software that has to be checked and authorized again.