Method for comparing two binary codes

Abstract

The invention relates to a method for comparing two binary codes for an automated driving function of a motor vehicle, said method comprising the following steps: generating two dissimilar binary codes from a same source code for an automated driving function of a motor vehicle such that the generated binary codes each have reference blocks which reference the source code, forming superblocks by merging the reference blocks for each of the binary codes, respectively assigning the superblocks formed for one of the two binary codes to the superblocks formed for the other of the two binary codes in order to obtain pairs of superblocks, based on the reference blocks, applying at least one software quality metric to each pair of superblocks, in order to obtain, as a result, a measure in each case, wherein the measure describes a similarity of the two superblocks of the pairs, comparing the two binary codes based on the obtained measures. The invention also relates to a device, to a computer program and to a machine-readable storage medium.

Description

[0001] Description

[0002] title

[0003] Method for comparing two binary codes

[0004] The invention relates to a method for comparing two binary codes for a driving function of a motor vehicle, a device, a computer program and a machine-readable storage medium.

[0005] State of the art

[0006] Disclosure document WO 2023 / 004184 A1 discloses a method for monitoring a road.

[0007] The patent application EP 3 674 920 A1 discloses a method for creating map data.

[0008] Disclosure WO 2022 / 081421 A1 discloses a method for data transfer within an infrastructure.

[0009] Disclosure of the invention

[0010] The object underlying the invention is to provide a concept for efficiently comparing two binary codes for an automated driving function of a motor vehicle.

[0011] This problem is solved by means of the respective subject matter of the independent claims. Advantageous embodiments of the invention are the subject matter of dependent claims. According to a first aspect, a method for comparing two binary codes for an automated driving function of a motor vehicle is provided, comprising the following steps:

[0012] Generating two dissimilar binary codes from an identical source code for an automated driving function of a motor vehicle such that the generated binary codes each have reference blocks to the source code,

[0013] Forming superblocks by merging the reference blocks for each of the binary codes, matching the superblocks formed for one of the two binary codes to the superblocks formed for the other of the two binary codes to obtain pairs of superblocks based on the reference blocks, applying at least one software quality metric to each pair of superblocks to obtain a measure as a result, where the measure describes a similarity of the two superblocks of the pair, and comparing the two binary codes based on the obtained measures.

[0014] According to a second aspect, a device is provided which is set up to carry out all steps of the procedure according to the first aspect.

[0015] According to a third aspect, a computer program is provided which includes instructions that, when the computer program is executed by a computer, for example by the device according to the second aspect, cause it to execute a procedure according to the first aspect.

[0016] According to a fourth aspect, a machine-readable storage medium is provided on which the computer program is stored according to the third aspect.

[0017] The invention is based on the understanding that the above problem is solved by creating superblocks by merging the reference blocks for each of the binary codes and ordering these into pairs, such that a metric is calculated for each pair by applying at least one software quality metric to each pair of superblocks. Using a software quality metric, the similarity of the superblocks in a pair can be efficiently quantified by the metric, allowing the two binary codes to be efficiently compared based on the obtained metrics. In other words, the use of at least one software quality metric enables a quantitative comparison of the similarity of the two binary codes. Thus, the two binary codes can be efficiently compared.

[0018] For example, by generating two dissimilar binary codes from the same source code for an automated driving function of a motor vehicle, the technical advantage is achieved that two different binary codes are available, which can, however, fulfill the same function: an automated driving function.

[0019] As a general rule, if the binary code generated from the same source code is exactly the same, systematic errors will occur. In the context of automated driving, this can be detrimental from a safety perspective.

[0020] Typically, for example, in an automated driving function, two computers perform calculations, both running the same application software. A third computer can then be used, for instance, to verify the results from these two computers.

[0021] However, if both computers are running the exact same binary code, one result can be incorrect, yet the results from both computers will still match due to the identical binary code. At least partially automated driving based on an incorrect result can be detrimental and, for example, could lead to a collision.

[0022] Therefore, the plan is to generate two dissimilar binary codes from the same source code, so that the two computers performing calculations for at least partially automated driving are more heterogeneous with regard to their application software. Such heterogeneity advantageously provides protection against systematic errors.

[0023] However, the more different the binary code generated from the same source code is, the more the results can diverge. In other words, it should be ensured that both binary codes still calculate the same thing.

[0024] Therefore, in the context of automated driving of motor vehicles, it makes sense to compare such dissimilar binary codes with each other in order to make a statement as to whether the differences are too large, too small or sufficient to use the binary code in the context of automated driving of a motor vehicle.

[0025] The generation of dissimilar binary code from identical source code is known to those skilled in the art. In this process, the dissimilar binary code is generated from the same source code, which can also be referred to as source code in this description. The generation of each binary code includes references to the original source code. In other words, the dissimilar binary code is generated such that each generated binary code contains reference blocks to the source code.

[0026] These references, or reference blocks, include, for example, the name of the original source code file and the line number.

[0027] According to the concept described here, it is specifically intended that not entire binary code files are compared directly with each other, but rather the associated reference blocks, i.e., the pairs of superblocks. A reference can be associated, for example, if it points to the same source code file and the same line number.

[0028] In one embodiment of the method, it is provided that at least one software quality metric is selected from the following group of software quality metrics: Damerau-Levenshtein metric and longest-common metric.

[0029] This results, for example, in the technical advantage that particularly suitable software quality metrics can be used.

[0030] In one embodiment of the method, it is provided that the numerical values ​​are accumulated over all pairs, and the two binary codes are compared based on the accumulation.

[0031] This results, for example, in the technical advantage that the binary codes can be compared efficiently.

[0032] In one embodiment of the method, the accumulation includes summing the measure values ​​to obtain a sum of the measure values, and the two binary codes are compared based on the sum of the measure values.

[0033] This results, for example, in the technical advantage that the accumulation can be carried out efficiently, so that the two binary codes can be compared efficiently.

[0034] In one embodiment of the method, the accumulation includes relating the numerical values ​​to a reference quantity in order to obtain relative numerical values, with the two binary codes being compared based on the sum of the relative numerical values.

[0035] This results, for example, in the technical advantage that the accumulation can be carried out efficiently, so that the two binary codes can be compared efficiently.

[0036] In one embodiment of the method, the relating process includes relating the numerical values ​​to a number of superblocks as a reference quantity. This provides, for example, the technical advantage that the relating process can be carried out efficiently.

[0037] In one embodiment of the method, it is provided that the relating includes relating the numerical values ​​to a respective length of the corresponding superblocks as a reference quantity.

[0038] This results, for example, in the technical advantage that the process of relating data can be carried out efficiently.

[0039] In one embodiment of the method, the accumulation includes a statistical evaluation of the numerical values, wherein the two binary codes are compared based on the statistical evaluation.

[0040] This results, for example, in the technical advantage that the accumulation can be carried out efficiently, so that the two binary codes can be compared efficiently.

[0041] In one embodiment of the method, the statistical evaluation includes determining the dispersion of the measures and / or determining an average of the measures.

[0042] This results, for example, in the technical advantage that statistical evaluation can be carried out efficiently.

[0043] In one embodiment of the method, it is stipulated that the first reference block is a superblock.

[0044] This results, for example, in the technical advantage that the subsequent comparison can be carried out optimally.

[0045] Superblocks are not an optional construct, nor strictly speaking, are they an optimization. They arise from the fact that the toolchain can generate successive reference blocks, all pointing to the same source code reference. These reference blocks are then merged into a superblock to enable optimal comparison. It cannot always be assumed that the toolchain will cut the reference blocks for the two optimization levels into blocks of equal size. Only by merging them into superblocks (always for the same source code reference) can a meaningful comparison be performed later.

[0046] The toolchain for generating the assembly files consists in particular of the compiler and then the assembler.

[0047] In one embodiment of the method, it is provided that it is checked whether a reference block immediately following a superblock points to a library, and if so, then the reference block is merged with the superblock.

[0048] This results, for example, in the technical advantage that the merging process can be carried out efficiently.

[0049] In one embodiment of the method, it is provided that, if no, it is checked whether the one reference block points to the same reference as the one superblock, and if yes, the one reference block is merged with the one superblock.

[0050] This results, for example, in the technical advantage that the merging process can be carried out efficiently.

[0051] In one embodiment of the method, it is provided that, if no, it is specified that the reference block is a new superblock.

[0052] This results, for example, in the technical advantage that the merging process can be carried out efficiently.

[0053] In one embodiment of the method, the merging is performed independently of any argument from a command contained in the binary code. This provides, for example, the technical advantage of efficient merging.

[0054] In one embodiment of the method, it is provided that it is checked whether a superblock and a reference block immediately following the one superblock point to the same source code file and line number, and if so, the one reference block is merged with the one superblock.

[0055] This results, for example, in the technical advantage that the merging process can be carried out efficiently.

[0056] In one embodiment of the method, it is provided that it is checked whether a superblock and a reference block that point to the same source code file and line number immediately follow one another, wherein, if so, the one reference block is merged with the one superblock, wherein, if no, the one reference block is not merged with the one superblock.

[0057] This results, for example, in the technical advantage that the merging process can be carried out efficiently.

[0058] A merger as described includes in particular a merger of a reference block with another reference block and / or a merger of a reference block with a superblock.

[0059] Applying at least one software quality metric includes, for example, applying at least one software quality metric to a pair of superblocks up to the first jump instruction in one of the two superblocks. This means, for example, that the software quality metric is applied to the portion of the superblock containing the first jump instruction that extends to the first jump instruction, and to a corresponding portion of the other superblock.

[0060] In other words, a software quality metric is applied, for example, only to the portion of the superblock that extends to the first jump instruction. For instance, the software quality metric might check, for example, whether a jump instruction exists in one of the two superblocks, whether the other of the two superblocks also contains a jump instruction and / or a jump instruction at the same location as the first of the two superblocks. The metric then indicates the result of this check, i.e., whether the other of the two superblocks also contains a jump instruction and / or a jump instruction at the same location as the first of the two superblocks.

[0061] A superblock is, in particular, a list of machine instructions. These are executed sequentially until a jump instruction is encountered. Evaluating / comparing jump instructions can be very resource-intensive. Therefore, comparisons are often limited to the point where a jump instruction is encountered.

[0062] It should be noted here that there are several types of jump instructions. For example, it is determined whether there is a jump instruction on both sides, i.e., in both superblocks. For example, the length of the section before the jump instruction is determined. If there is no jump instruction, the relative length would be 100% of the total length of the superblock. For example, the jump instructions are compared with each other. The comparison is not continued after the jump instruction. For example, one superblock of a pair may not contain a jump instruction, but the other superblock of the pair may contain one. In such a case, both superblocks are compared, as described in the description, up to the point where the other superblock contains a jump instruction.

[0063] The concept described here is based, in particular, on the fact that, for example, the content of a jump instruction is not determined, nor is its destination determined. The comparison is specifically terminated when a jump instruction is present. For example, the algorithm is designed to compare jump instructions for equality in this case, implicitly but not explicitly. This means, for instance, that the algorithm does not perform a special comparison if the same jump instruction appears at the same position in both superblocks. For example, the algorithm is designed to always compare instructions by default; no distinction is made here as to whether jump instructions happen to be present in both superblocks.

[0064] The method is, for example, a computer-implemented method.

[0065] A software quality metric, as described, is a function that represents a software unit, in this case the pairs of superblocks, in a numerical value, in this case the measure, which can be interpreted as the degree of fulfillment of a quality property, in this case the similarity, of the software unit.

[0066] The source code, for example, is written or composed in the programming language C++.

[0067] Device features are derived analogously from corresponding process features, and vice versa. This means that the technical functionalities of the device result analogously from corresponding technical functionalities of the process, and vice versa.

[0068] The procedure is carried out, for example, using the device.

[0069] The device is, for example, a computer.

[0070] The device is, for example, programmed to execute the computer program.

[0071] The phrase “at least one” means “one or more”.

[0072] Statements made in connection with one software quality metric apply analogously to several software quality metrics and vice versa.

[0073] A driving function is, for example, a driving function that is at least partially automated. The term "at least partially automated" encompasses: partially automated, highly automated, fully automated, and autonomous. The exemplary embodiments and configurations described here can be combined with one another in any way, even if this is not explicitly stated.

[0074] The invention is explained in more detail below with reference to preferred embodiments. These include:

[0075] Fig. 1 shows a flowchart of a procedure for comparing two

[0076] Binary codes for an automated driving function of a motor vehicle,

[0077] Fig. 2 a device,

[0078] Fig. 3 a machine-readable storage medium,

[0079] Fig. 4 shows a flowchart of process steps,

[0080] Figs. 5-7 each show an exemplary fusion of reference blocks and

[0081] Fig. 8 shows a superblock.

[0082] Fig. 1 shows a flowchart of a procedure for comparing two binary codes for an automated driving function of a motor vehicle, comprising the following steps:

[0083] Generate 100 of two dissimilar binary codes from an identical source code for an automated driving function of a motor vehicle such that the generated binary codes each have reference blocks to the source code; form 103 of superblocks by merging the reference blocks for each of the binary codes; assign 105 the superblocks formed for one of the two binary codes to the superblocks formed for the other of the two binary codes to obtain pairs of superblocks based on the reference blocks; apply 107 at least one software quality metric to each pair of superblocks to obtain a measure as a result, wherein the measure describes a similarity of the two superblocks of the pair; compare 109 the two binary codes based on the obtained measures.

[0084] Fig. 2 shows a device 201 which is set up to carry out all steps of the method according to the first aspect.

[0085] Fig. 3 shows a machine-readable storage medium 301 on which a computer program 303 is stored. The computer program 303 comprises instructions which, when executed by a computer, cause the computer program 303 to perform a procedure according to the first aspect.

[0086] Fig. 4 shows a flowchart of process steps, as they can be used as an example in the process according to the first aspect.

[0087] According to step 401, it is determined that the first reference block is the first superblock.

[0088] Step 403 checks whether the next reference block points to a library.

[0089] If so, according to step 405, the next reference block is added to the current superblock, in this case the first superblock.

[0090] If not, step 407 checks whether the next reference block points to the same source reference.

[0091] If so, proceed to step 405.

[0092] If not, a new superblock is started with this next reference block according to step 409. In other words, step 409 determines that the next reference block is a new superblock. The flowchart can then continue, for example, in step 403. The process can continue, for example, until no more reference blocks can be merged into superblocks.

[0093] Fig. 5 shows, by way of example, a first reference block 501, a second reference block 503, a third reference block 505 and a fourth reference block 507.

[0094] The first reference block 501 points to the following reference: Source file 1: Line 12.

[0095] The second reference block 503 points to the following reference: Source file 1, line 12.

[0096] The third reference block 505 points to the following reference: Source file 1, line 14.

[0097] The fourth reference block 507 points to the following reference: Source file 1, line 18.

[0098] The first reference block 501 and the second reference block 503 are merged into a first superblock 509, symbolically represented by a curly brace. The first superblock 509 has the following reference: Source file: line 12.

[0099] It is further specified that the third reference block 505 is a second superblock 511 with the following reference: Source file 1: Line 14.

[0100] The third reference block 505 was therefore not merged with the first superblock 509 because it does not point to the same reference. The third reference block 505 points to line 14 of the first source file, whereas the two reference blocks 501 and 503 point to the same line 12 of source file 1. According to the concept described here, it is then determined, for example, that the fourth reference block 507 is a third superblock, which is not shown in detail in Fig. 5.

[0101] Fig. 6 shows a first reference block 601, a first library 603, a second reference block 605 and a third reference block 607.

[0102] Library 603 lies between the first reference block 601 and the second reference block 605.

[0103] The first reference block 601 points to the following reference: Source file 1 : Line 12.

[0104] Library or library block 603 points to line 99.

[0105] The second reference block 605 points to the following reference: Source file 1 : Line 12.

[0106] The third reference block 607 points to the following reference: Source file 1 : Line 14.

[0107] The first reference block 601, the library 603 and the second reference block 605 are merged into a first superblock 609.

[0108] The third reference block 607 forms a second superblock 611, and is therefore not merged with the first superblock 609, as it references a different line number.

[0109] Fig. 7 shows a first reference block 701, a first library block 703, a second reference block 705, a third reference block 707 and a fourth reference block 709.

[0110] The first reference block 701 points to the following reference: Source file 1 : Line 12.

[0111] The first library block 703 points to line 99. The second reference block 705 points to the following reference: Source file 1: line 12.

[0112] The third reference block 707 points to the following reference: Source file 1 : Line 14.

[0113] The fourth reference block 709 points to the following reference: Source file 1: Line 12.

[0114] According to the concept described here, the first reference block 701, the first library block 703 and the second reference block 705 are merged into a first superblock 711.

[0115] The third reference block 707 forms a second superblock 713 and is not merged with the first superblock 711, insofar as the third reference block 707 points to a different reference, in this case line 14.

[0116] The fourth reference block 709 points to the same reference as the first reference block 701 and the second reference block 705. However, the third reference block 707 is located between the fourth reference block 709 and the first superblock 711 or the second reference block 705, so the fourth reference block 709 is not merged with the first superblock 711.

[0117] The concept described here of comparing two dissimilar binary codes generated from the same source code is particularly advantageous in the field of automated driving.

[0118] An example of such automated driving is automated driving within the framework of an AVP process. AVP stands for "Automated Valet Parking," which can be translated into German as "automatischer Parkvorgang" (automatic parking process).

[0119] Particularly in the AVP context, a so-called "Safety PLC" is used, for example. "PCL" stands for "Programmable Logic Controller." This safety PLC is a hardware component used to bring an AVP infrastructure into a safe state if, for example, an implausible condition is detected by a safety monitor. The use of such hardware is technically complex, expensive, and requires extensive maintenance. Therefore, it is advantageous to eliminate the need for such hardware.

[0120] This can be achieved, for example, by replacing the security PLC with three computers. Application software runs on two of these computers. The third computer serves, for example, only to verify the results calculated independently by the first two computers. Previously, the same application software always ran on these two computers. However, this poses security risks that should be mitigated or minimized, which can be efficiently achieved by the concept described here.

[0121] Generally speaking, the more heterogeneous a system is, the more secure it is. However, such heterogeneity comes at a price. Therefore, there is a tension between highly diverse binary codes and exactly identical binary codes, each generated from the same source code.

[0122] While highly diverse binary code exhibits significant heterogeneity, which can offer protection against systematic errors, it can also lead to substantial additional effort in its creation and maintenance. Furthermore, it requires proof that the software still performs the same function, which can be very complex.

[0123] On the other hand, exactly identical binary code is very susceptible to systematic errors. However, the additional effort required to generate it is zero, and proving that the exactly identical binary code performs the same function is trivial, since it is exactly the same binary code.

[0124] From a security perspective, according to the concept described here, dissimilar binary code is generated from identical source code. The two binary codes are then compared to assess their similarity. Based on the result of this comparison, a decision is made, for example, as to whether the binary code may be used for an automated driving function.

[0125] Thus, within the framework of the concept described here, a measurement method for the distinctiveness of such a generated binary code is revealed.

[0126] The concept described here involves the generation of dissimilar binary codes. The generation of dissimilar binary codes is state of the art. The following conditions are met when generating the dissimilar binary code:

[0127] The binary code is generated from the same source code. When generating the binary code, references to the original source code must be included. These references are the name of the original source code file and the line number.

[0128] Instead of directly comparing entire code files, associated reference blocks are compared. A reference is associated, for example, if it points to the same source code file and line number.

[0129] For example, only the actual command is taken into account, for example "push", not the arguments of the command, for example the memory address.

[0130] For example, reference blocks are merged to form superblocks. During the merging process, the superblock receives the reference information from the merged reference blocks.

[0131] If a reference to a library is located between the reference blocks and does not point to one of the source code files, for example, this library or library block is merged with the preceding superblock.

[0132] In the exemplary representation shown in Fig. 7, the fourth reference block 709 has the same reference as the first reference block 701 and the second reference block 705. However, no merge is performed because another superblock, the second superblock 713, is located between them. In such a case, for example, the fourth reference block 709 is ignored.

[0133] The comparison of binary codes is based on the difference of the superblocks. In other words, the difference of the superblocks is calculated.

[0134] For example, according to the concept described here, there are several ways to calculate the difference.

[0135] For example, the Damerau-Levenshtein metric and / or the longest common metric are used.

[0136] By applying the Damerau-Levenshtein metric, questions such as the following can be answered: How many assembly line swaps are needed to convert one sequence of binary instructions of one binary code into the other sequence of binary instructions of the other binary code?

[0137] The following example should illustrate this:

[0138] The Damerau-Levenshtein algorithm or the Damerau-Levenshtein metric is adapted as follows, for example:

[0139] Instead of calculating the distance between two words, the distance between two lists of words (or assembly commands) is calculated. Each letter corresponds to one word.

[0140] Example:

[0141] "Already" -> "Look"

[0142] 1. Replace o with a

[0143] 2. n by u

[0144] Adaptation: Already

[0145] Look

[0146] tennis

[0147] Look

[0148] Already

[0149] tennis

[0150] 1. Swap "Look" and "Already"

[0151] What was done above for the letters in the two words "Schon" -> "Schau" is done below for words in two lists "Schon, Schau und Tennis" and "Schau, Schon und Tennis".

[0152] A replacement is treated specifically as a deletion plus insertion and therefore has a cost of 2. (In contrast to a cost of 1 in the original, i.e., unadapted, Damerau-Levenshtein algorithm.)

[0153] The following example will explain the application of the longest common metric.

[0154] The "longest common metric" answers, in particular, the following question:

[0155] "What is the longest identical sequence of assembly instructions?" The metric here is therefore specifically the longest identical sequence of assembly instructions.

[0156] The "longest common metric" specifically seeks the longest substring of two strings that is contained in both strings.

[0157] The "longest-common metric" can be extended to operate on a list of words (instead of, for example, a sequence of letters). It also takes jump instructions into account.

[0158] A jump instruction can occur within a superblock. As soon as this happens, the comparison, for example, ends immediately after the jump instruction. The knowledge of whether an instruction is a jump instruction is common to those skilled in the art.

[0159] Example

[0160] Commands in the superblock:

[0161] 1 : pop

[0162] 2: add

[0163] 3: jne

[0164] 4: pop

[0165] Line 3 is a jump instruction. For example, only lines 1-3 are considered for the comparison.

[0166] Accumulation of metrics for a binary code

[0167] Typically, both binary codes contain multiple superblocks that can be compared. For efficient comparison, it is particularly advantageous to accumulate the respective measures. In particular, one or more of the following three statistical methods are especially useful or can be used, for example:

[0168] 1. Simple summation

[0169] 2. Simple summation of relative values:

[0170] 2.1 Metric based on the number of superblocks compared

[0171] 2.2 Or metric based on the length of the respective superblocks being compared

[0172] 2.3 Or a combination of 2.1 and 2.2.

[0173] 3. Extended statistical analyses 3.1 For example: What is the dispersion of the metrics and the average across all compared superblocks?

[0174] In general, the following applies in particular:

[0175] The higher the calculated Damerau-Levenshtein value (the numerical value resulting from applying the Damerau-Levenshtein formula), the more different the binary codes are.

[0176] The smaller the longest common value (a measure resulting from applying the Damerau-Levenshtein method), the more different the binary codes are.

[0177] Fig. 8 symbolically shows a superblock 801 comprising a first jump instruction 803. The part of the superblock 801 up to and including the first jump instruction 803 is indicated by a curly brace with the reference numeral 805. The part of the superblock 801 after the first jump instruction 803 up to the end of the superblock 801 is indicated by a curly brace with the reference numeral 807.

[0178] In other words, superblock 801 is a superblock that contains a single jump instruction. Therefore, superblock 801 can be divided into part 805, up to and including the jump instruction, and part 807, from the jump instruction to the end of superblock 801. The software quality metric, for example, is applied only to part 805, not to the entire superblock, but only to the part that includes the jump instruction.

[0179] For example, it may be stipulated that part 801 only extends to the first jump instruction 803, and that part 807, after the first jump instruction 803, up to the end of superblock 801, may or may not include the first jump instruction.

[0180] This means, for example, that the portion of superblock 801 up to, but not including, the first jump instruction 803 is designated by the curly brace with the reference 805. The portion of superblock 801 after the first jump instruction 803, and including or excluding it, up to the end of superblock 801, is designated by a curly brace with the reference 807.

[0181] In other words, superblock 801 is a superblock that contains a single jump instruction. Therefore, superblock 801 can be divided into part 805, which includes or excludes the single jump instruction, and part 807, which extends from the jump instruction to the end of superblock 801. The software quality metric, for example, is applied only to part 805, not to the entire superblock, but only to the part that includes or excludes the jump instruction.

[0182] For example, it may be intended that part 805 does not include the first jump instruction, and yet the software quality metric is applied to that one part 805 and to the first jump instruction.

[0183] For example, the part of the superblock on which the software quality metric is applied can be called a partial superblock.

[0184] In summary, the concept described here includes one or more of the following steps:

[0185] 1. Create two binary-different executable files from one source code.

[0186] 2. Form the superblocks by merging and pair them using the source code references.

[0187] 3. For each pair, generate the two metrics: Damerau-Levenshtein* and Longest-Common*

[0188] 3.1 A Damerau-Levenshtein that is as large as possible is good.

[0189] 3.2 A longest common that is as small as possible is good.

[0190] 4. Accumulate the value over all pairs

[0191] 5. In a next step, threshold values ​​will be provided for the metrics that indicate that the binary code is sufficiently different from a security point of view.

Claims

Claims 1. A method for comparing two binary codes for an automated driving function of a motor vehicle, comprising the following steps: Generating (100) two dissimilar binary codes from an identical source code for an automated driving function of a motor vehicle such that the generated binary codes each have reference blocks (501 , 503, 505, 507) to the source code, Forming (103) superblocks (509, 511, 609, 611, 711, 713) by merging the reference blocks (501, 503, 505, 507) for each of the binary codes, respectively matching (105) the superblocks (509, 511, 609, 611, 711, 713) formed for one of the two binary codes to the superblocks (509, 511, 609, 611, 711, 713) formed for the other of the two binary codes to obtain pairs of superblocks (509, 511, 609, 611, 711, 713) based on the reference blocks (501, 503, 505, 507), Applying (107) at least one software quality metric to each pair of superblocks (509, 511, 609, 611, 711, 713) to obtain a measure as a result, wherein the measure describes a similarity of the two superblocks (509, 511, 609, 611, 711, 713) of the pair, Comparing (109) the two binary codes based on the obtained numerical values.

2. The method of claim 1, wherein the at least one software quality metric is selected from the following group of software quality metrics: Damerau-Levenshtein metric and longest-common metric.

3. Method according to claim 1 or 2, wherein the numerical values ​​are accumulated over all pairs, and the two binary codes are compared based on the accumulation.

4. The method of claim 3, wherein the accumulation comprises summing the measure values ​​to obtain a sum of the measure values, wherein the two binary codes are compared based on the sum of the measure values.

5. Method according to claim 3 or 4, wherein the accumulation comprises relating the numerical values ​​to a reference quantity in order to obtain relative numerical values, wherein the two binary codes are compared based on the sum of the relative numerical values.

6. Method according to claim 5, wherein the relating comprises relating the numerical values ​​to a number of superblocks (509, 511, 609, 611, 711, 713) as a reference quantity.

7. Method according to claim 5 or 6, wherein the relating comprises relating the dimensional values ​​to a respective length of the corresponding superblocks (509, 511 , 609, 611 , 711 , 713) as a reference quantity.

8. Method according to any one of claims 3 to 7, wherein the accumulation comprises a statistical evaluation of the numerical values, wherein the two binary codes are compared based on the statistical evaluation.

9. Method according to claim 8, wherein the statistical evaluation comprises determining a dispersion of the measures and / or determining an average of the measures.

10. Method according to any of the preceding claims, wherein the first reference block (501 , 503, 505, 507) is a superblock.

11. Method according to one of the preceding claims, wherein it is checked whether a reference block (501 , 503, 505, 507) immediately following a superblock points to a library, wherein, if so, the one reference block (501 , 503, 505, 507) is merged with the one superblock.

12. Method according to claim 11, wherein, if no, it is checked whether the one reference block (501 , 503, 505, 507) points to the same reference as the one superblock, wherein, if yes, the one reference block (501 , 503, 505, 507) is fused with the one superblock.

13. Method according to claim 12, wherein, if no, it is specified that the one reference block (501 , 503, 505, 507) is a new superblock.

14. Method according to any of the preceding claims, wherein the merging is performed independently of any argument of an instruction encompassed by the binary code.

15. Method according to one of the preceding claims, wherein it is checked whether a superblock and a reference block (501 , 503, 505, 507) immediately following the one superblock point to the same source code file and line number, wherein, if so, the one reference block (501 , 503, 505, 507) is merged with the one superblock.

16. Method according to any of the preceding claims, wherein it is checked whether a superblock and a reference block (501, 503, 505, 507) that point to the same source code file and line number immediately follow one another, wherein, if so, the one reference block (501, 503, 505, 507) is merged with the one superblock, wherein, if no, the one reference block (501, 503, 505, 507) is not merged with the one superblock.

17. Device (201) which is configured to perform all steps of the method according to any of the preceding claims.

18. Computer program (303) comprising instructions which, when the computer program (303) is executed by a computer, cause it to execute a method according to any one of claims 1 to 16.

19. Machine-readable storage medium (301) on which the computer program (303) according to claim 18 is stored.

Images