Patent Application
20240037015
The present application claims the benefit under 35 U.S.C. § 119 of German Patent Application DE 10 2022 207 613.3 filed on Jul. 26, 2022, which is expressly incorporated herein by reference in its entirety.
The present invention relates to a computer-implemented method for verifying a software component of an automated driving function. The present invention also relates to a software component of the automated driving function which has been verified using the provided method, and to a computer-implemented system for implementing an automated driving function, comprising at least one software component which has been verified using the provided method.
Computer-implemented methods for verifying a software component, i.e., model checking methods, are described in Gerking, C., Dziwok, S., Heinzemann, C., Schafer, W., “Domain-Specific Model Checking for Cyber-Physical Systems,” Proceedings of the 12th Workshop on Model-Driven Engineering, Verification and Validation (MoDeVVa 2015), Ottawa, September 2015; Kwiatkowska, M., Norman, G., Sproston, J., “Probabilistic Model Checking of the IEEE 802.11 Wireless Local Area Network Protocol,” Joint International Workshop on Process Algebra and Probabilistic Methods, Performance Modeling and Verification—Process Algebra and Probabilistic Methods: Performance Modeling and Verification, pages 169-187, 2002; and Konig, L., Pfeiffer-Bohnen, F., Schmeck, H., “Theoretische Informatik—ganz praktisch [Theoretical Information Technology—In Practice],” De Gruyter Studium, September 2016, chapter 2.4.
An object of the present invention is to provide an improved computer-implemented method for verifying a software component of an automated driving function and an improved system for implementing the driving function.
This object may be achieved by features of the present invention. Advantageous configurations and developments of the present invention are disclosed herein.
The present invention provides a computer-implemented method for verifying at least one software component of an automated driving function. According to an example embodiment of the present invention, the method comprising the following steps:
The current state of the art in industrial development processes is testing whether driving functions, action planners, fusion algorithms, and other control modules have been correctly implemented. Methods such as simulation-based testing are often used in this case; however, they do not guarantee that errors are discovered. In contrast, model checking is a general verification method for software on the basis of automatic formal proof.
In this process, a program is translated into a model and checked for “correctness”. The term “correctness” is flexible depending on context, but is specified by precise mathematical formalisms (for example, temporal-logical formulas). Model checking analyzes all possible sequences in the program and outputs whether or not a given specification is fulfilled in all cases (and if not, under what circumstances it is not fulfilled). Examples of corresponding tools for model checking are
In order to facilitate efficient model checking of existing program code (e.g., in C++, Python, etc.), it is necessary to translate the program code into a format or representation that the model checker can use. This step is generally performed manually by a developer. Approaches that automatically generate model checking problems are typically based on domain-specific modeling languages (DSML) and not on programming languages in C++ or the like.
According to an example embodiment of the present invention, it is particularly worthwhile to use the proposed method in safety-critical applications having large state spaces (for example having approx. 1020 to 1030 states) which can only be partially covered by testing alone. This relates in particular to driver assistance systems, automated driving functions, robots, aircraft controllers, autonomous ships, etc. This is because the environment model can advantageously limit the state space of the software component to be verified by way of predefinable boundary conditions and therefore contribute to the more efficient processing of the existing program code. In this case, the environment model can equally be provided in the form of a native environment model program code.
The translation process being presented here according to the present invention is particularly advantageously tailored for use in a production context for safety-critical systems (which generally have very large state spaces having the aforementioned number of states and are therefore complex to verify), i.e., with a focus on:
In a further specific embodiment of the present invention, the native program code of the software component to be verified and the environment model program code are limited to a set of operations of the at least one programming language used that are defined as permissible.
Advantageously, by suitably limiting the native program code of the software component to be verified and the environment model, full automation can be obtained. For full automation, it is important, for example, to limit the C++/Python/etc. code to a set of operations of the programming language that are defined as permissible (in a simple variant, for example, by dispensing with all the loop/GoTo/recursion structures, or, with a positive formulation, by using logical operators, comparative operators, arithmetic operators, instructions for setting variables, so-called set instructions, e.g., for changing system variables, decision operations in the form of branches, e.g., if-else instructions, sequence operations, and a numerical range), which are then, in the translation process, converted into at least one finite automaton which forms the basis for generating the at least one model checker representation for the analysis by way of model checking methods.
In a further specific embodiment of the present invention, the environment model describes boundary conditions for starting states of the software component to be verified and/or boundary conditions for changes in the state of the software component to be verified. By the environment model describing boundary conditions for starting states of the software component to be verified and/or boundary conditions for changes in the state of the software component to be verified, it is possible to limit the state space of the software component to be verified. This state space can, for example, be limited by restricting the content of the variables to what is possible in the real world. In the context of automated driving, this could relate to statements regarding physics and the behavior of other drivers, for example. Without an environment model, the model checker would check invalid sequences in which, for example, a vehicle “jumps” from one lane to the other or from being in front to being behind. This both slows down the process and results in “false positives,” i.e., in unrealistically strict statements regarding errors (for example, the above-mentioned “jump” could generate cut-ins which are not even physically possible, and this could result in the safety distance not being maintained, which a driving algorithm could not prevent). In this way, reliability and safety can thus advantageously be improved.
In a further specific embodiment of the present invention, during the translation, the native program code of the software component to be verified and the environment model program code are transferred into the structure of a common finite automaton. The model checker representation limited by the boundary conditions of the environment model and intended for the software component to be verified is generated on the basis of the common finite automaton. The proposed method can advantageously be adjusted flexibly to the existing native program code or to the respective safety-critical applications and provides clear, readily understood, and biunique structures for the model checking method.
In a further specific embodiment of the present invention, at least in a first step, during the translation of the native program code of the software component to be verified and the environment model program code, at least one intermediate representation of the software component to be verified and/or of the environment model is generated which has the structure of a finite automaton (FA segments), in which at least part of the native program code (code segment) is embedded. This advantageously facilitates fully automatic model checking for regular programming languages. The proposed method is also advantageously programming language-agnostic, i.e., at least all the conventional procedural, object-oriented, and functional programming languages are suitable for said method. Therefore, the proposed method provides greater flexibility than conventional prior-art methods. The model checker representation is also formally unique, in contrast with conventional methods based on test scenarios.
In a further specific embodiment of the present invention, in at least one further step, during the translation of the native program code of the software component to be verified and the environment model program code, the at least one code segment of the at least one intermediate representation is converted into FA segments. This advantageously facilitates fully automatic model checking for regular programming languages. Therefore, the proposed method provides greater flexibility than conventional prior-art methods. The model checker representation is also formally unique, in contrast with conventional methods based on test scenarios.
In a further specific embodiment of the present invention, at least in a first step, the program code of the software component to be verified and the environment model program code are each transferred, independently of one another, into a separate intermediate representation having the structure of a finite automaton. In at least one further step, these two intermediate representations are transferred into a common finite automaton, on the basis of which the model checker representation for the software component to be verified is generated. The proposed method can advantageously be adjusted flexibly to the existing native program code or to the respective safety-critical application and provides clear, readily understood, and biunique structures for the model checking method.
In a further specific embodiment of the present invention, the software component of the automated driving function forms an adaptive cruise control (ACC) function for an automated vehicle. In this case, the ACC function includes distance control, lane keeping assist, and optionally other sub-functions. The proposed method can advantageously be used in the design period for the system (accessibility to the runtime) in order to, for example, check the correctness of the driving function, e.g., the proposed ACC function, an action planner, or another control module in an automated vehicle.
In this case, the method is technically advantageously not limited to the context of automated driving or to a driving function of this kind, but rather can also be applied in other software modules, provided that they can be defined as finite automata. It is particularly worthwhile to use said method in safety-critical applications having large state spaces which can only be partially covered by testing alone. This relates in particular to driver assistance systems, automated driving functions, robots, aircraft controllers, autonomous ships, etc. The proposed method can advantageously replace parts of the testing process and thus contribute to savings in terms of cost and time.
In a further specific embodiment of the present invention, the model checking method is performed using the NuSMV tool on the basis of computation tree logic (CTL) or linear temporal logic (LTL). It is particularly advantageous here that the present invention can be used universally and flexibly and is in particular compatible with commonplace tools.
In addition, a software component of an automated driving function which has been verified using the above-mentioned method is provided according to the present invention. This in particular provides a high level of flexibility and simple practicability in the development period.
Furthermore, according to an example embodiment of the present invention, a computer-implemented system is provided for implementing an automated driving function, comprising the at least one above-mentioned software component which has been verified using the proposed method.
The advantageous configurations and developments of the present invention that are disclosed herein can be used in isolation but also in any combination with one another, except, for example, where there are distinct dependency references or incompatible alternatives.
The above-described properties, features, and advantages of the present invention and the manner in which they are achieved become clearer and more readily comprehensible in conjunction with the following description of exemplary embodiments, which are explained in greater detail in conjunction with the schematic figures.
It should be noted that the figures are merely schematic in nature and are not to scale. As such, components and elements shown in the figures may be shown much larger or smaller to aid understanding. Furthermore, it should be noted that the reference signs in the figures have been selected to be the same when they relate to identical elements and/or components.
The above-mentioned environment model is understood to be a limitation of the system behavior to be checked to what is “physically possible,” “realistic,” or “sufficiently approximate,” in order to facilitate a productive analysis. This means that the environment model includes a description of:
In this case, the first two points are geared in particular toward realism, in order to prevent “false positives” (in the sense of reported errors which are not really errors at all), and the third point is geared toward facilitating an efficient simulation by reducing the size of the state space. This is because, without an environment model, the model checker would potentially check invalid sequences in which, for example, a vehicle “jumps” from one lane to the other or from being in front to being behind. This both slows down the model checking process and results in “false positives,” i.e., in unrealistically strict statements regarding errors (for example, the above-mentioned “jump” could generate cut-ins which are not even physically possible, and this could result in the safety distance not being maintained, which a driving algorithm or automated driving function could not prevent).
In this case, the environment model is provided in the form of a native environment model program code 110, 210, and, as already mentioned, is used to limit the state space of the software component to be verified by way of predefinable boundary conditions for starting states and/or boundary conditions for changes in the state of the software component to be verified. Particularly safety-critical applications having large state spaces (for example having approx. 1020 to 1030 states) which can only be partially covered by testing alone advantageously benefit from the proposed principle 15 of the present invention, namely the provision of an environment model 101, 201. Safety-critical applications may be, e.g., driver assistance systems, highly automated driving functions, robots, aircraft controllers, autonomous ships, etc.
The environment model 110, 210 and the software component 105, 205 to be verified, which is likewise specified in the form of a native program code, are first pre-processed 20. This means the native program codes 105, 205, 110, 210 are each translated 115, 215 fully automatically into an intermediate representation 207, 213 which has the structure of a finite automaton (FA segments), in which at least part of the native program code (code segment) is embedded. The process can be referred to as “mining,” for example.
The two intermediate representations 207, 213 are lastly translated into a model checker representation, which, e.g., has a pure FA form (in particular, for this purpose, the at least one code segment is converted into FA segments) and can be processed by a model checker. The model checking 120 is carried out on the basis of the model checker representation and, as shown, is used for evidence of correctness.
For example, this can be achieved by dispensing with all the loop/GoTo/recursion structures, or, with a positive formulation, by using logical operators, comparative operators, arithmetic operators, instructions for setting variables, so-called set instructions, e.g., for changing variables or system variables, decision operations in the form of branches, e.g., if-else instructions, sequence operations, and a numerical range.
The software component to be verified by way of model checking is likewise described by native program code 105. This is preferably likewise limited to the above-mentioned set of operations that are defined as permissible. The native program code of the software component 105 to be verified and the native environment model program code 110 are translated in a second step 115. In the translation process, in the second step 115, a model checker representation limited by the boundary conditions of the environment model is generated. This can, for example, take place such that, during the translation, the native program code of the software component 105 to be verified and the native environment model program code 110 are transferred into the structure of a common finite automaton (FA). The model checker representation limited by the boundary conditions of the environment model is lastly generated on the basis of the common FA. In a third step 120, the model checker representation is verified by way of a model checking method on the basis of the model checker representation generated in the preceding step. For example, the model checking method can be performed using the NuSMV tool on the basis of computation tree logic (CTL) or linear temporal logic (LTL).
In an alternative configuration, the second step 115 in
In a second sub-step, during the translation of the native program code of the software component 105 to be verified and the environment model 110, the at least one code segment of the at least one intermediate representation 207, 213 is converted into FA segments. The first and the second sub-step can likewise lead to, during the translation, the native program code of the software component 105 and the environment model 110 being transferred into the structure of a common finite automaton, and to the model checker representation, which is limited by the boundary conditions of the environment model 110, being generated on the basis of precisely this common finite automaton.
In contrast with the method 100 in
The two intermediate representations 207, 213 are lastly transferred into a common finite automaton 217, on the basis of which the model checker representation 219 for the software component to be verified is generated. A third step 220 in
For example, the software component to be verified can form an adaptive cruise control (ACC) function for an automated vehicle and be implemented as follows as native C++ program code 105, 205:
In this code, “egoSpeed” can be a variable or system variable which represents the ego speed of the automated vehicle and “frontCarSpeed” can be a variable or system variable which represents the speed of another vehicle located in the environment of the automated vehicle, i.e., for example, a vehicle traveling in front, and “SPEED STEP” can describe a speed step. At this juncture, it is already apparent that the speed of the other vehicle located in the environment of the automated vehicle (“frontCarSpeed”) is not known without using an environment model, and therefore there is also no change in said speed or said variables/system variables, but rather only in the speed (“egoSpeed”) of the automated vehicle.
An associated environment model 110, 210 which has been specially adjusted to the above ACC driving function as the software component 105, 205 to be verified can, for example, look as follows in C++ code:
The environment model 110, 210 can, for example, limit the state space of the variables/system variables “egoSpeed” and “frontCarSpeed” by way of predefinable boundary conditions, with the predefinable boundary conditions being able to represent, in said example, the consideration of the position of the vehicle traveling in front (“frontCarPos”) and the use of an accuracy regulation (see above: quantization by the introduction of a geometric grid, or the like) of the situation in question via “DISTANCE_STEP”. Said boundary conditions can relate both to the starting states of the variables/system variables and/or to the changes in state of said variables/system variables. In this case, a starting state can also be understood to be a limited value range of a variable/system variable, for example.
The environment model 110, 210 thus facilitates, inter alia, a calculation of the positions/speeds/etc. of other vehicles in the environment of the automated vehicle, with a set of possibilities being able to be (non-deterministically) specified if an aspect is unclear at the current moment, for example whether another vehicle will accelerate (“std::min(SPEED_MAX, frontCarSpeed+1)”) or brake (“std::max(SPEED_MIN, frontCarSpeed−1)”) in the next step. In particular, the above environment model 110, 210, in combination with the ACC function indicated above as the software component 105, 205 to be verified, can be used to better verify whether, for example, it is possible for the vehicle to be driven without an accident occurring by considering the position of a vehicle traveling in front. Therefore, the environment model 110, 210 not only advantageously improves the performance of a model checking method and the associated computing resources by suitably limiting the state space of the software component to be verified, but also makes a significant contribution to the safety of an automated vehicle comprising the software component 105, 205, to be verified, of the automated driving function.
In the example shown in
On the basis of the finite automaton 217, the model checker representation 219 is generated, which is lastly verified by way of a model checking method. For example, the model checking method can be performed using the NuSMV tool on the basis of computation tree logic (CTL) or linear temporal logic (LTL), as also explained above.
Advantageously, the use of the environment model 110, 210 can contribute to limiting the state transitions in the FA or in the intermediate form of the FA in order to generate a realistic and efficient simulation. For example, the result of the environment model 110, 210 in
It goes without saying that the features explained in conjunction with
Lastly, it is expressly noted that, in addition to the above-described method 100, 200, 300 for verifying a software component of an automated driving function, the present invention also relates to a software component verified in accordance with the present invention and to a computer-implemented system for implementing the automated driving function, which comprises at least one software component verified in accordance with the present invention.
The present invention has been described in detail on the basis of preferred exemplary embodiments. Instead of the exemplary embodiments described, further exemplary embodiments which can include further modifications to or combinations of described features are possible. For this reason, the present invention is not limited to the disclosed examples since a person skilled in the art may derive other variations therefrom without departing from the scope of the present invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 10 2022 207 613.3 | Jul 2022 | DE | national |
