Translation of behavior tree into petri net for model checking

Abstract

To provide a computer-implemented method for verifying autonomous behavior of a system that is at least partially autonomous.SOLUTION: An autonomous behavior is based on implementation of a behavior tree. A method comprises steps of translating a behavior tree, or an alternative representation of the behavior tree, into a Petri net, and of checking the autonomous behavior, on the basis of the Petri net, thereby generating a test result.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Conventional technology Behavior trees originate from the game development community, where they are a reactive and easy way to implement deliberations for non-playable characters. Their structure, which represents the control flow of a system, makes them an easily graspable model of the system's behavior, as well as a concrete implementation of what runs within the system and ultimately steers / controls that system. [Background technology]

[0002] Recently, the development of at least partially autonomous systems has utilized behavior trees to represent deliberations and policy switching in the system's implementation. For example, behavior trees have gained attention in robotics due to their simplicity and ability to describe reactive behavior and contingency policies. Furthermore, the rapid development of tools for programming and incorporating behavior trees into robotic frameworks, such as the Robot Operating System (ROS), a set of libraries, drivers, and algorithms for implementing robotic applications, has fueled their popularity.

[0003] However, when moving to (safety) critical applications like robotics, self-driving cars, and / or autonomous systems in general, despite all the advantages of such behavior trees, they are not a well-defined formalism, which makes direct (formal) verification of the properties of the model, also known as model checking, difficult or even impossible.

[0004] (Formal) verification is important for many different reasons: to check that the system works as intended in certain situations, to make sure that the system is safe, to check if there are performance limitations (e.g. the battery may not be sufficient for the task), to show limitations of the implementation, etc.

[0005] Model checking, as used herein, refers to formal methods in the field of offline model checking, i.e., the systematic construction and exploration of the state space of a given formal model to verify given logical properties, which is often much faster and less expensive than running non-exhaustive testing methods on real systems.

[0006] As noted above, developers are increasingly adopting the use of behavior trees to implement the functionality of their systems. However, while behavior trees of an implementation already provide an initial informal model, a formal model is required for model checking. In contrast to behavior trees, Petri nets are formal models used in many application domains, from planning to imitation, and have proven useful and performant for formal verification. For example, with tools such as STORM and GreatSPN, Petri nets lend themselves well to verifying the robustness of properties expressed in temporal logic in robotics applications. Summary of the Invention [Problem to be solved by the invention]

[0007] Therefore, the technical problem to be solved in this disclosure can be seen as providing a means to bridge the gap between informal behavior trees and model checking. [Means for solving the problem]

[0008] Disclosure A first general aspect of the present disclosure relates to a computer-implemented method for verifying autonomous behavior of an at least partially autonomous system, where the autonomous behavior is based on a behavior tree implementation. The method includes translating the behavior tree or another representation of the behavior tree into a Petri net. The method may further include checking the autonomous behavior based on the Petri net, thereby generating test results.

[0009] A second general aspect of the present disclosure relates to a computer system configured to perform a computer-implemented method for verifying autonomous behavior of an at least partially autonomous system according to the first general aspect (or an embodiment thereof).

[0010] A third general aspect of the present disclosure relates to a computer program configured to perform a computer-implemented method for verifying autonomous behavior of an at least partially autonomous system according to the first general aspect (or an embodiment thereof).

[0011] A fourth general aspect of the present disclosure relates to a computer-readable medium or signal storing or encoding a computer program of the third general aspect (or an embodiment thereof).

[0012] Behavior trees have recently gained traction in robotics for the deliberative design and implementation of control policies. Unfortunately, behavior trees lack the universally accepted formal definition and associated verification methods needed to improve confidence in the correct behavior of at least partially autonomous systems, such as robots, in practical applications.

[0013] The above problem is solved by a method of a first general aspect (or an embodiment thereof). Indeed, one of the core features of the method is to translate behavior trees into Petri nets to enable verification of the modeled behavior in terms of temporal-logical properties, for example, using a prior art model checker. In other words, the resulting Petri nets are used as a proxy for verifying the behavior modeled by the behavior trees.

[0014] In some embodiments, the translation disclosed below takes a behavior tree, individually translates the nodes of the behavior tree into so-called Petri subnets (each of these Petri subnets is a Petri net), and assembles and optionally optimizes these Petri subnets into an equivalent model-checkable Petri net. Equivalence is achieved by a Petri net structure that mimics the behavior tree so that verification results of the Petri net can be transferred back to the behavior tree.

[0015] In doing so, developers of at least partially autonomous systems benefit from being able to work with behavior trees, which are then translated into equivalent Petri nets, allowing for formal verification based on Petri nets.

[0016] If the test results are negative, the behavior tree can be corrected and checked again by repeating the method of the first general aspect (or an embodiment thereof), thereby improving the at least partially autonomous system.

[0017] In some embodiments, the method may include one or more optimization steps that maintain the functionality of the resulting translated Petri net while simultaneously reducing the computational complexity of the Petri net. The resulting general Petri net (a Petri subnet without optimization, also called a template Petri subnet) from a behavior tree may not scale well in the context of model checking (because such a general Petri net is too large for efficient model checking in terms of places, transitions, etc.). Fortunately, it has been found that by optimizing such a general Petri net (or its building blocks), efficient model checking in relevant use cases is still possible. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 illustrates a schematic diagram of an exemplary embodiment of a computer-implemented method for verifying the autonomous behavior of an at least partially autonomous system. [Figure 2a] FIG. 1 illustrates a particular illustrative embodiment of a computer-implemented method for verifying the autonomous behavior of an at least partially autonomous system. [Figure 2b] FIG. 1 illustrates a particular illustrative embodiment of a computer-implemented method for verifying the autonomous behavior of an at least partially autonomous system. [Figure 3a] FIG. 1 is a diagram illustrating an example behavior tree for a robot navigating autonomously in one-dimensional space. [Figure 3b] FIG. 3b schematically illustrates another representation (eg, an execution flow graph) of the exemplary behavior tree of FIG. 3a. [Figure 4a] FIG. 1 is a diagram illustrating a schematic of markings in a Petri net. [Figure 4b] FIG. 1 is a diagram illustrating a schematic of markings in a Petri net. [Figure 4c]FIG. 1 is a diagram illustrating a Petri net interface representation. [Figure 5a] FIG. 10 shows a schematic diagram of a (first) template Petri subnet for an execution node of a behavior tree. [Figure 5b] FIG. 10 shows a schematic diagram of a (second) template Petri subnet for a control flow node of a behavior tree. [Figure 5c] FIG. 10 shows a schematic diagram of a (second) template Petri subnet for a control flow node of a behavior tree. [Figure 6a] FIG. 3b shows a schematic representation of a (non-optimized) Petri net resulting from translating the exemplary behavior tree of FIG. 3a; [Figure 6b] FIG. 3b shows a schematic diagram of a contextual optimization of a Petri net resulting from translating the exemplary behavior tree of FIG. 3a; [Figure 6c] 3b shows a schematic representation of an optimization based on the execution flow graph of a Petri net resulting from translating the exemplary behavior tree of FIG. 3a; FIG. DETAILED DESCRIPTION OF THE INVENTION

[0019] Detailed Description As an example, imagine a developer of a home vacuum robot that uses behavior trees to implement a deliberative system. During development, the developer is interested in docking maneuvers and whether, if a docking station for recharging is found, this docking station is reached within, say, 10 seconds. Satisfying this property allows for better safety, since the robot never runs the risk of running out of battery before it can reach the docking station and recharge. This also improves energy management, since the robot can plan to use less energy to return to recharge, allowing it to spend more energy cleaning the house, potentially faster.

[0020] Such an exemplary behavior tree 10 is shown in Figure 3a. This exemplary behavior tree should be construed as non-limiting, as the method 100 can be applied to any behavior tree 10.

[0021] This example may relate only abstractly to the vacuum cleaner robot described above and its at least partially autonomous behavior. In this example, the behavior of a robot traveling autonomously in one-dimensional space, i.e., on a horizon, is described, attempting to find a location called home (e.g., a location in one-dimensional space where the robot is recharged). The robot can detect its relative position (home or to the right or left) and move independently in either direction. Starting at the root node 11 of the behavior tree, it checks 12 whether the robot is already at home. If not, the behavior tree 10 is traversed from left to right by checking 15 whether the robot is located to the left of the home location. If this is the case, the robot travels one discrete step to the right. If this is not the case, the next subtree is executed, checking 17 whether the robot is located to the right of home, and a left travel is performed. This tree can be run for a given time or permanently, ie execution continues at the root node 11 after a run or while the robot is at home.

[0022] As shown schematically in FIG. 2a, an exemplary embodiment of method 100 can start with a set of requirements for a system's functionality, e.g., the functionality of a vacuum cleaner, represented by a behavior tree (abbreviated as BT). The behavior tree can then be translated into a Petri net (abbreviated as PN). This translation method can be based on small Petri nets (hereinafter referred to as template Petri subnets) that mimic the functionality of a single node in the behavior tree. For example, the template Petri subnet can be the most general, parametric, modular Petri net that represents the behavior of the corresponding behavior tree node type. These small Petri nets can then be assembled into a single Petri net that maintains (by construction) properties similar to those of the behavior tree. This single Petri net can be passed to a prior art model checker to verify that the system requirements are maintained.

[0023] For example, as shown in Figure 2a, a behavior tree and one or more requirements for functionality, particularly one or more requirements for the autonomous behavior of the system, can be input. One or more behavior tree (BT) nodes can then be individually translated into Petri net (PN) templates (hereinafter also referred to as template Petri subnets), optionally including one or more contextual optimizations. For example, as shown in Figure 2a, multiple Petri net templates can be assembled into a single Petri net. Then, model checking is performed based on the single Petri net and one or more requirements.

[0024] Further features of an exemplary embodiment of method 100 are illustrated diagrammatically in FIG. 2b. Again, application of the method can begin with a developer creating several behavior trees that implement the functionality of a vacuum cleaner, for example, to meet the requirements for docking maneuvers as specified above. At the end of the implementation, the developer will have the behavior tree, e.g., as an XML file, obtained from many prior art libraries, such as BehaviorTree.cpp., along with some metadata representing additional information possessed by the system. This XML specification of the behavior tree can be used in a translation method to generate a Petri net that models the behavior of the behavior tree. For example, the developer invokes the translation method implementation on the XML file and obtains a Petri net output, e.g., in the form of a PNML (Petri Net Markdown Language) file. Furthermore, the user can specify the level of optimization of the resulting Petri net. The resulting Petri net file can then be used as input for a model checker, such as Storm, invoked by the developer. Furthermore, a developer formulates the property that the developer wants to verify on the system in terms of one or more logical expressions (e.g., one or more conditions). When the model checker finishes its operation, it returns that the property is satisfied for the model, i.e., that there is no possible execution of the system in which the property is violated; or, the model checker can return that the property is not satisfied in a particular execution and even provide a counterexample. Some model checkers return the probability that the property is satisfied in the system. The developer then needs to determine whether the results provided by the model checker are acceptable for their implementation, and if not, modify the system's behavior tree accordingly to improve the results. This process can be automated by machine learning algorithms that translate the test results of the model checking procedure into changes to the behavior tree to improve the results.

[0025] For example, in FIG. 2b, a developer may consider the (intended) behavior of the system and one or more assumptions and / or requirements for functionality, particularly one or more requirements for the system's autonomous behavior. The developer may then create and / or modify a behavior tree (BT), which represents the system functionality. A routine for BT-to-PN translation for model checking may then be invoked. By doing so, the behavior tree (BT) nodes may be converted into Petri net (PN) templates (hereinafter also referred to as template Petri subnets), optionally including one or more contextual optimizations and / or execution flow graph-based optimizations. For example, as shown in FIG. 2b, multiple Petri net templates may be assembled into a single Petri net. Then, based on the single Petri net and one or more requirements, a model check is performed to verify whether one or more assumptions / requirements for the system functionality hold (as intended). The conclusion is a test result. For example, as shown in Figure 2b, the test result may be positive (OK), indicating that the system meets one or more assumptions / requirements. On the other hand, the test result may be (partially) negative (nOK), if the system does not meet the assumptions / requirements. In this case, the behavior tree (BT) can be modified ("learned from lessons") to correctly represent the desired functionality. For example, as shown in Figure 2b, the modified behavior tree can be input again into the routine for BT-to-PN translation for model checking. Such iterations can be repeated as necessary.

[0026] In the case of a robot, a behavior tree may be a description, in the form of a tree, of the control structure for the agent's behavior. A behavior tree may describe an execution plan that defines under what conditions which tasks should be executed or under what conditions one task should be switched to another. Such behavior trees can be used to describe complex control flows and decision-making by breaking down an overall function into smaller subtasks that are combined in a modular, intuitive, and / or human-readable format. A behavior tree may include one or more leaf nodes that represent atomic functions and skills that can be performed by an at least partially autonomous system (also referred to as a system, e.g., robot). Internal nodes may represent logic that determines which leaf node or nodes are executed in what order during execution of the at least partially autonomous system, as well as conditions that should be evaluated to determine how to proceed in that execution.

[0027] The intuitive structure of behavior trees has led to their widespread use in tools such as the BehaviorTree.cpp C++ library, which implements task planning using behavior trees, and the ROS Navigation2 toolset, where agent policy switching is described using behavior trees for navigator task orchestration. Due to the graphical nature of behavior trees, behavior trees can be developed efficiently using tools such as GROOT, which allows for graphical assembly of the nodes defined above to obtain the desired behavior tree structure.

[0028] The behavior tree 10 may be a directed, rooted tree, where the internal nodes 11, 13, and 14 may be referred to as control flow nodes, and the leaf nodes 12, 15, 16, 17, and 18 may be referred to as execution nodes. By definition, each control flow node has at least one child. With respect to such children, the control flow node is a parent (node).

[0029] A behavior tree can start its execution from a root node 11, which generates signals called "ticks" at a given frequency, each of which triggers the execution of a node. Nodes can represent conditions to be evaluated in the current state of the system and possible actions. A ticked node (i.e., a node that has just received a "tick") can immediately return a signal to its parent node: "Running" (abbreviated as "R") if the node's execution is currently taking place, a signal: "Success" (abbreviated as "S") if the node's execution achieved its goal, or a signal: "Failure" (abbreviated as "F") if it did not. Additionally, there is a signal: "Halt" (abbreviated as "H") that can be used to stop any running node, allowing a parent node to stop its children and prevent them from colliding with preceding running nodes if a contingency is required. Execution nodes provide inputs to and outputs from the environment in which the system, defined by the behavior tree, operates, allowing the system to be responsive. Each control flow node type explicitly handles whether and in what order "ticks" are delivered to its child nodes. A special type of control flow node is the decorator. A decorator has exactly one child and expresses custom behavior depending on the return signal of that child. With respect to return signals, different control flow node types can behave as follows: In a reactive sequence node (abbreviated "→") or fallback node (abbreviated "?"), all children are searched in order and return their current status as soon as they are ticked. If one node fails, all other running nodes in the sequence are stopped. In a reactive sequence, if all children return "Success", the parent returns "Success", otherwise if one child returns "Running" or "Failure", the parent returns "Running" or "Failure". In a fallback node, the roles of "Success" and "Failure" are reversed. A sequence node with memory (abbreviated as "→*") or a fallback node ("?*") does the same as above, except that children that have already returned "success" or "failure" respectively in the previous "tick" cycle are not ticked again. A parallel node (abbreviated as "⇒n over k") ticks all n children in order and waits until all have returned. If more than k children return "Success", the parallel node returns "Success". If n-k+1 children return "Failure", the parallel node returns "Failure", otherwise it returns "Running". The Invert node (abbreviated as "￢"), a type of decorator node, returns the opposite of the result of its child, and "running" and "stopped" have the opposite meanings. ·Decorator Force Success Node ("

number

[0030] In the example behavior tree for a 1D robot in Figure 3a, some of the most commonly used node types can be identified, for example, two different execution nodes represented by ellipses 12, 15, 17 (condition nodes) and rectangles 16, 18 (action nodes). Additionally, two different control flow nodes are represented by squares 11, 13, 14. The square nodes with arrows 13, 14 are reactive sequence nodes ("→"), while the square node with question mark ("?") 11 is a reactive fallback node.

[0031] Behavior trees are typically used in conjunction with a Blackboard, a data structure that can hold global variables related to the execution of the system. This data structure can be thought of as the memory or state of the system and its environment. This data structure separates the data used within the Behavior Tree from its execution logic. While this description represents the prior art as implemented in libraries such as BehaviorTree.cpp found in textbooks, it is neither formal enough for validation nor universally accepted by the majority of implementations of Behavior Trees in the community.

[0032] A Petri net can be represented by a bipartite graph that can represent the distribution, conditional transfer, and transformation of resources within the modeled system. This bipartite graph can be achieved by activation of nodes called transitions (represented by rectangles), which move and / or transform resources and send them to distinct locations called places (represented by circles) where they can be collected. The distribution of resources can be referred to as the marking of the Petri net and is graphically represented by tokens (dots) in the different places of the net. Such markings in Petri nets 30a and 30b are shown schematically in Figures 4a-4b.

[0033] To represent time in Petri nets, transitions can be associated with probability distributions. Furthermore, transitions can have probabilistic outcomes.

[0034] In general, Petri nets can be represented as interfaces. An interface can completely ignore the internal structure of the Petri net it represents. For example, an interface can focus rather on inputs, outputs, and the time delay distribution between receiving the inputs and returning the outputs. An interface representation of an exemplary Petri net 30c is shown schematically in FIG. 4c.

[0035] Disclosed is a computer-implemented method 100 for verifying the autonomous behavior of an at least partially autonomous system (such as a robot or an autonomous vehicle), where the autonomous behavior is based on the implementation of a behavior tree 10. The behavior tree 10 is merely an explicit and non-limiting example.

[0036] The method 100 includes translating 120 the behavior tree 10 or another representation 20 of a behavior tree into a Petri net 30a, 30b, 30c, 50, 60, 70. This may be the translation step needed to bridge the gap between behavior trees and formal model checking. This works best when the Petri net 50, 60, 70 is functionally equivalent or sufficiently functionally equivalent to the behavior tree 10. As noted above, instead of translating the behavior tree 10, the method may include translating 120 another representation 20 of the behavior tree 10. For example, this representation may be an execution flow graph resulting from removing one or more control flow nodes from the behavior tree 10. Again, such a representation need not necessarily be a behavior tree (indeed, the root node may be removed, e.g., as in FIG. 3b), but such a representation is functionally equivalent to a behavior tree.

[0037] The method 100 may further include checking 140 the autonomous behavior based on the Petri net 50, 60, 70, thereby generating a test result. Checking 140 the autonomous behavior may include checking whether or to what extent the autonomous behavior is intended by one or more requirements for the autonomous behavior. Checking 140 the autonomous behavior may include applying a model checker based on the Petri net 50, 60, 70. For example, the Petri net may be checked by the model checker. For this purpose, for example, a prior art Petri net model checker, such as STORM or GreatSPN, may be used. The model checker may be a probabilistic model checker.

[0038] 1 shows a schematic representation of an embodiment of the method, including steps 120 and 140. An alternative representation 20 of the behavior tree 10 results from optimizing 110 the behavior tree, as shown schematically as an option in FIG.

[0039] Depending on the test result, one or more actions can be defined. For example, method 100 may include indicating 141 that the autonomous behavior is verified if the test result is positive ("OK" in FIG. 1). Alternatively or additionally, method 100 may include indicating 142 that the autonomous behavior is not verified and / or that the autonomous behavior needs to be adjusted if the test result is negative ("nOK" in FIG. 1). A similar dependency on the test result is also shown in FIG. 2b.

[0040] 1, translating 120 the behavior tree 10 or another representation of a behavior tree 20 into a Petri net 50, 60, 70 may include translating 121 one or more nodes 11, 12, 13, 14, 15, 16, 17, 18, 22, 25, 26, 27, 28 of the behavior tree 10 or another representation of a behavior tree 20 into a corresponding Petri subnet 40a, 40b, 40c, 40d. Each of the Petri subnets may be a first template Petri subnet 40a or a second template Petri subnet 40b, 40c. Alternatively, each of the Petri subnets may be an optimized version of the first template Petri subnet 40a or the second template Petri subnet 40b, 40c.

[0041] Then, again as shown schematically as an option in FIG. 1, translating 120 the behavior tree 10 or another representation of the behavior tree 20 into a Petri net 50, 60, 70 may further include assembling 125 one or more Petri subnets 40a, 40b, 40c, 40d based on the behavior tree 10 and / or another representation of the behavior tree 20, thereby generating the Petri net 50, 60, 70.

[0042] 1, translating 121 one or more nodes of the behavior tree 10 or another representation 20 of the behavior tree into corresponding Petri subnets may include translating 122 one or more execution nodes 12, 15, 16, 17, 18, 22, 25, 26, 27, 28 of the behavior tree 10 or another representation 20 of the behavior tree into corresponding Petri subnets. Alternatively or additionally, again as optionally illustrated schematically in FIG. 1, translating 121 one or more nodes of the behavior tree 10 or another representation 20 of the behavior tree into corresponding Petri subnets may include translating 123 one or more control flow nodes 11, 13, 14 of the behavior tree 10 or another representation 20 of the behavior tree into second template Petri subnets 40b, 40c.

[0043] In other words, the translating 120 can be based on creating (in the memory of the computer system) one template Petri subnet for each node of the behavior tree or another representation of the behavior tree 20. The template Petri subnet may be the most general parametric modular Petri net that can represent the behavior of the corresponding node type. As mentioned above, there are at least two node types to be processed, namely: An execution node that models the system and its connections with its environment; Control flow nodes that implement the logic for traversing the behavior tree, defining how execution nodes can be reached in the correct order and determining which node should be executed (next); exists.

[0044] For example, the first template Petri subnet 40a, as shown schematically in FIG. 5a, is a template Petri subnet for an execution node. The first template Petri subnet 40a may include a Petri net place that receives "tick" or "stop" signals (sometimes called colors) for different Petri net token types and sends those tokens to an interface ("Environment") that models the environment and how the behavior tree interacts with this environment. On the right side are transitions for all possible return signals ("Success," "Failure," "Running") of the behavior tree node, which may also be represented by different token colors (for different Petri net token types). This may be considered the most general case. On the other hand, in the simplest case, when all outcomes are independent of the environment and have equal probability, the "tick" and "stop" transitions and the environment can be deleted, and the main place can be connected to the return signal transition to close the self-loop.

[0045] For example, the second template Petri subnet 40b (along with 40c) as shown schematically in Figures 5b and 5c is a template Petri subnet for control flow nodes. Control flow nodes are used to implement the internal evolution of a running behavior tree. Generally, control flow nodes may tick only one child at a time and have a single "tick" signal passing through them.

[0046] To replicate the behavior in the second template Petri subnet, one transition can be added to the template Petri subnet for each possible signal in the behavior tree, and the activation of this transition depends on the state of the corresponding behavior tree node. Behavior tree nodes and their states can be represented in the template Petri subnet by places containing the following six token types (colors): A "tick" token in a template Petri subnet indicates the presence of a "tick" signal in the corresponding behavior tree node. · "Stop" token is the same as above for the "Stop" signal. The number of "counter" tokens indicates how many children have already returned their signal. The number of "Running" tokens indicates how many children returned "Running". · The same applies to the "success" token and its corresponding return signal. The same applies to the "failure" token and its corresponding return signal.

[0047] These token color markings represent the state of the behavior tree node in the Petri net. The conditional activation of children in the behavior tree is then translated into a Petri net with conditions on the number of tokens required in a place for the activation of the arc. Similarly, it defines how many tokens of what type are sent to the next place. These conditions can be expressed as vector notation on the arc. Furthermore, priorities can be assigned to ensure that only one of the applicable transitions is activated at a time.

[0048] The general structure of the second template Petri subnet is shown schematically in Figures 5b and 5c. Figure 5b shows the (complete) second template Petri subnet, where simplified interfaces show the inputs from the parent central place, where the node states are indicated by markings, and the signals sent to the children (square boxes). These children receive input signals from transitions and return one of three return signals via left-pointing arrows (also called arcs). Figure 5c shows the (complete) interface of a child (square box). This child is one of the children (square boxes) of Figure 5b.

[0049] In Figure 5b, a (complete) second template Petri subnet is shown with a central place containing tokens encoding the state of the corresponding behavior tree node. The central place receives "stop" and "tick" signals from its parent on the left and forwards these signals to the squares representing its children's interfaces. In return, the central place receives one update for each child. Figure 5c shows the general Petri net interface of a possible child node, simply displaying its inputs and outputs. Each specific node type template can later be derived from this general structure by selecting the notation of each arc and the priority of each transition to achieve the desired behavior. To represent the behavior of parallel nodes in a Petri net, a template structure similar to Figure 5b, with some modifications, can be used. Again, all n children get their parent's signal in sequence. The calculation of the return signal is performed differently by summing the number of "counter" tokens that track how many children have returned and the number of return tokens of each type ("success," "failure," or "running"). To calculate the return signal of the main place, n "counter" tokens in the main place are required. The conditions for the return signal of a parallel node are "succeeded" if a specified number k of children succeed, "failed" if n-k+1 failed, and "running" otherwise. After each transition for the return signal is activated, the main place is emptied and the status of the Petri net is reset for the next execution.

[0050] When one or more nodes of the behavior tree 10, in particular each of the nodes of the behavior tree 10, are translated into corresponding Petri subnets, the corresponding Petri subnets (e.g., a first template Petri subnet and / or a second template Petri subnet) are assembled 125 into Petri nets 50, 60, 70.

[0051] For example, the assembly of individual Petri subnets works by substituting the corresponding Petri nets of the behavior tree nodes they represent for the generic interface of the template Petri subnet, ensuring that the structure given by the behavior tree is consistent (or maintained). This is illustratively illustrated in FIG. 6a for the behavior tree 10 of the 1D robot shown in FIG. 3a. Places and transitions representing the nodes of the 1D robot are surrounded by rounded rectangles with the same color as the corresponding nodes in the behavior tree of FIG. 3a and the following names: Petri net transitions are labeled with "T" for "tick," "H" for "stop," "S" for "success," "F" for "fail," and "R" for "return."

[0052] The method 100 (or, as shown generally in FIG. 1 , translating 120 the behavior tree 10 or another representation of a behavior tree 20 into a Petri net 50, 60, 70) may include optimizing 126 one or more Petri subnets based on meta-information about the at least partially autonomous system, the at least partially autonomous system's environment, and / or the behavior tree 10 or another representation of a behavior tree 20. Such optimization may be considered a contextual optimization (see execution flow graph-based optimization, described below).

[0053] The node-by-node translation into templates and assembly of these templates can result in a functional and very general representation, albeit an inefficient representation, of the behavior tree's functionality as a Petri net. This inefficiency stems from the generality of the translation itself, since it makes the system large and some elements redundant, which makes model checking unnecessarily expensive. Therefore, a method is provided that uses additional, specific contextual information about the system, its domain, and the nature of the behavior tree to streamline and optimize the translation 120. This improves performance when model checking the resulting Petri nets 50, 60, 70. At least two optimization approaches exist: Contextual optimization utilizes additional contextual and domain knowledge of the environment and / or specific system functionality to remove redundant and unused elements of the template. Execution flow graph-based optimizations utilize the characteristics of control flow nodes, excluding parallel nodes, to reduce the number of nodes in the system by summarizing sequences of control flow nodes while preserving the properties of the execution nodes. This allows for a significant reduction in the number of nodes, at the expense of losing the possibility to check properties for each specific control flow node.

[0054] To obtain higher performance for model checking, these two approaches can be optionally applied individually and only partially during the translation process. In the following, a detailed description of the implementation of the above two approaches is presented.

[0055] The intuition behind contextual optimization is that by fixing certain values ​​and removing unused elements of each Petri subnet, it is possible to achieve a more efficient representation, both in terms of readability of the system description and model checking. This can be done by exploiting contextual information and domain knowledge of concrete system functions, i.e., by exploiting additional information about the environment, the behavior tree, or their interactions.

[0056] For example, the optimization can be performed in three steps: Timed transitions are immediate: For each transition, we check whether the transition can be immediate by checking whether the gamma distribution that approximates the timing of the transition encodes immediate firing, i.e., whether the mean latency is close to zero and the standard deviation is low. Eliminate unnecessary arcs and transitions: These unnecessary arcs and transitions may include components of the Petri net that will never be executed because certain values ​​will never appear in a concrete instance of the modeled system. Furthermore, arcs with probability 0 (or a sufficiently low probability) are removed, and arcs with probability 1 (or a sufficiently high probability) are made non-probabilistic. Reduce the number of colors: For example, if a particular return signal never occurs, unused token colors are removed. This reduces the dimension of the Petri net's state representation.

[0057] In the case of the exemplary 1D robot of Figure 3a, the contextual optimization may be as follows: For example, in this example, when evaluating the nodes "is at home", "is left", and "is right", there is no concrete environment from which the robot's position can be derived. Therefore, by assuming equal probability that the three conditions are met, it is possible to abstract from any concrete environment. Having these concrete values ​​simplifies the system while maintaining full generality. Furthermore, due to domain knowledge regarding 1D robots, the following simplifications can be made: All timed transitions in Petri nets can be instantaneous because the execution of actions in a behavior tree is considered instantaneous. There is no "stop" signal in 1D robots because all execution nodes are executed immediately and atomically, which means that they cannot be interrupted with respect to their execution. All execution nodes can only return "success", because in a concrete implementation, running to the right or left cannot fail, i.e., "running" and "failed" transitions can be removed.

[0058] At the end of the process, we obtain the Petri net shown in Figure 6b. Compared to Figure 6a, the behavioral nodes have only one transition corresponding to the "success" signal because they are atomic. The control flow nodes have only two transitions instead of three because the "running" signal is not used in the immediate transition. Finally, there is only one transition connecting each control flow node to its child because the "stop" signal is not used. Each color of the arc notation represents one of six token types in a given order. This contextual optimization preserves the bisimilarity relationship between the original behavior tree and the translated Petri net. Because this contextual optimization merely imposes additional knowledge implicit in the behavior tree on the Petri net, it does not modify the relationship between the evolutionary steps in the behavior tree and the activation of transitions in the Petri net, which by definition preserves these two bisimilarity relationships.

[0059] 1, the method 100 may further include optimizing 110 the behavior tree 10, thereby generating an alternative representation 20 of the behavior tree 10. For example, the alternative representation 20 of the behavior tree 10 may be an execution flow graph that results from removing one or more control flow nodes from the behavior tree 10.

[0060] In contrast to contextual optimization, execution flow graph-based optimization can be performed already at the beginning of the procedure, starting from the original behavior tree, because some of its structure can be simplified and merged before translating it into a template Petri subnet. To describe this optimization procedure, additional terminology is introduced. All control flow node types, except for parallel nodes, are called summarizable because the decision of which child to explore next or what to return depends only on the currently explored child for these node types. There is no need to recall the conclusions of previously explored nodes. In contrast, execution nodes and parallel nodes that do not have children to be summarized are non-summarizable because they need to keep track of the state of previously explored children. (It is also possible to convert these nodes to be summarizable by adding more token colors and helper structures to the template Petri subnet of the parallel node, but this may result in a more efficient optimization of the translation procedure at the expense of increased complexity.) Execution flow graph-based optimization includes the following steps: Constructing an execution flow graph: For every sequence of summarizable nodes in the behavior tree (e.g., the root fallback node 11 and its two sequence node children 13, 14 in the exemplary 1D robot of Fig. 3a), an execution flow graph is constructed, whereby every non-summarizable node (in this example, an execution node) is connected to the non-summarizable node that will be subsequently ticked depending on the summarizable node's logic and return signal. Fig. 3b shows the execution flow graph for the exemplary 1D robot of Fig. 3a, where each execution node is connected to the execution node that will be next ticked given the return signal and the logic of the fallback and sequence nodes. Constructing a Petri net using the execution flow graph: This execution flow graph can be used to obtain a simplified model of the system. This model can then be converted into a Petri net by translating each of the model's nodes into a template, as described above for individual behavior tree nodes, and assembling template Petri subnets using the structure provided by the execution flow graph. Connections between template Petri subnets may be implemented by proceeding directly to the next non-summarizable node, or through an additional summarizable node added as the root of the resulting Petri net. The choice of whether to add such an additional root node must be made by considering how the properties for model checking the Petri net are ultimately to be formulated. Connecting to an additional root node can make property writing more intuitive and requires less knowledge about the sequence of nodes, while not connecting to an additional root node reduces the number of places and transitions in the resulting Petri net, but requires knowledge of the order of execution to write the properties. If no additional root nodes are added, each sequence of summarizable nodes is modeled as a single transition with a single token for activating the transition. Otherwise, the sequence is implemented as summarizable nodes (see Figures 5b-5c), the interfaces are replaced by non-aggregatable nodes, and the conditions for activation of the arcs are modified to maintain the same execution order as defined in the execution flow graph. Assembling timed transitions: Direct connection of non-summarizable node templates with the execution flow graph can result in sequences of timed transitions that do not occur in an unoptimized Petri net. If timed transitions exist in the original behavior tree description, after constructing the Petri net using the execution flow graph, two different assembly methods can be chosen: (1) Memory-efficient solution: A gamma distribution assembly computed as a convolution of gamma distributions can generally be approximated as a gamma distribution, where the parameter α is the sum of the individual αi and β is computed by solving an optimization problem. This reduces the memory requirements of the resulting transitions from storing two parameters per transition in the original sequence to three parameters, but at the expense of some loss of accuracy due to the imperfect approximation. The third parameter, even if not a parameter of the gamma distribution itself, refers to the delay as a function of all distributions with sufficiently small standard deviations and can be viewed as the translation of a time parameter for some fixed delay k equal to the sum of the means of gamma distributions with sufficiently small standard deviations. Mathematically, the gamma distribution of a sequence of transitions can then be written as G(tk,α,β). (2) Precision-efficient solution: In this case, the distribution is sampled into discrete series, and a discrete convolution is performed on these discrete series to obtain the resulting series. All parameters of the components must be stored, but the precision of the results can be controlled by changing the sampling frequency. The higher the frequency, the more precise the results, but the longer the calculation time.

[0061] For example, after the above three execution flow graph-based optimization steps are applied to a 1D robot together with contextual optimization, a Petri net like the one shown in Fig. 6c is obtained. In the execution flow graph-based optimization, an additional root node of the sequence of summarizable nodes is used.

[0062] 1, the method 100 may further include optimizing 130 the Petri nets 50, 60. For example, the contextual optimization and / or execution flow graph-based optimization described above may be implemented at any stage of the method 100, or even, for example, only within the constructed Petri nets.

[0063] Further optimization of the Petri net is possible.

[0064] For example, as another or final optimization step, a Petri net can be converted to a colorless one, i.e., one with only one token color, by mapping each return signal ("success," "failure," or "running") and the receiving non-summarizable node of the behavior tree to a specific number of tokens required for arc activation. If the Petri net does not have roots added for each series of summarizable nodes, the number of tokens can represent which signal types pass through the Petri net. For example, one token in the main place of a template Petri subnet represents "tick," while two tokens represent "stop," and the tree indicates a "success" return signal. If a series of roots is added to the Petri net, this mapping to the number of tokens indicating the next node to be executed is done by tracing the path of a signal, e.g., "tick," in the execution flow graph (Figure 3b) and indexing the nodes in search order. These indexes are then used as the number of tokens required to advance processing by the corresponding node during execution. If there is more than one signal used in a behavior tree, for example, if there is a "stop" signal in addition to a "tick" signal, these two index sequences must be distinguished. One simple solution is to assign all odd integer sequences to "tick" and all even integer sequences to "stop." Applying this optimization step to the example 1D robot, we can further transform the Petri net, converting the vector of token colors required for arc activation into a single number. While execution flow graph-based optimization does not preserve bisimilarity between the initial behavior tree and the corresponding Petri net, it does preserve all properties that rely on signals reaching non-summarizable nodes. Because all information about summarizable nodes is summarized, there are states in the behavior tree that do not exist in the generated Petri net, which would destroy bisimilarity.The unsummarized nodes still preserve the same bisimilarity they had with the unoptimized or contextually optimized system, which means that all of the properties associated with them are maintained.

[0065] The ability to back-translate the results of model checking on Petri nets into the initial behavior tree relies on the notion of equivalence of both (i.e., pre-translated and post-translated) representations. The proof is outlined as follows: The argument is made by induction starting from the following assumptions: Templates behave similarly to the node types they represent, i.e. the way the templates are constructed is correct. The behavior of a child from the parent's point of view can be abstracted by only considering the return signals that the child gives to the parent, while ignoring the internal state of the child, the state of these children, or any other external variables.

[0066] To prove that we can make these assumptions, we need to do two steps: the first step is to mimic a template Petri subnet for each node type and verify that we get the correct behavior for all possible return signals of the children (this was done during development). The second step is to recall that interfaces are used in templates to represent children that do not depend on any state or variables, but only on inputs.

[0067] Relying on these assumptions, we can begin the proof by induction. A base case is obtained by considering leaf nodes. These leaf nodes are translated into interfaces, so they model the correct behavior by construction. Going up one level, the level below can be simplified as an interface, and the templates behave as the node types they represent (according to the first assumption). This implies that each Petri net at this level behaves as a corresponding subtree in the behavior tree. Similar reasoning can be applied to any level above, with fewer and fewer subtrees obtained at each level. This process continues until there is exactly one tree and exactly one Petri net that still maintains the same behavior starting from the template corresponding to the root of the behavior tree.

[0068] 1, the method 100 may further include adjusting 150 the behavior tree 10 or another representation of a behavior tree 20 based on the test results. For example, a (pre-trained) machine learning algorithm may be used to adjust 150 the behavior tree 10 or another representation of a behavior tree 20. Alternatively, the behavior tree 10 may be manually adjusted 150 based on the test results.

[0069] 1, method 100 may further include repeating 160 method 100. In other words, method 100 may be repeated, or other embodiments of method 100 may be re-executed. Such may be useful for checking the adjusted 150 behavior tree or the adjusted 150 representation of the behavior tree. Such iterations may be repeated as needed.

[0070] Additionally, a computer system configured to perform the computer-implemented method 100 for verifying the autonomous behavior of an at least partially autonomous system is disclosed. The computer system may include a processor and / or a memory.

[0071] Further disclosed is a computer program configured to perform the computer-implemented method 100 for verifying the autonomous behavior of an at least partially autonomous system. The computer program may be, for example, in an interpretable or compiled form. The computer program may be (even partially) loaded into a computer's RAM for execution, for example, as a string of bits or bytes.

[0072] Further disclosed is a computer readable medium or signal having stored thereon and / or encoding the computer program. The medium may include, for example, one of a RAM, a ROM, an EPROM, a HDD, an SSD, etc., on which the signal is stored.

[0073] Further disclosed is an at least partially autonomous system (abbreviated as system) that includes non-volatile storage that stores or encodes an implementation of a behavior tree (e.g., a compiled computer program) that causes the autonomous behavior of the system. The at least partially autonomous system may be designed or configured as an (industrial) robot, a self-driving vehicle, a smart home system (including autonomous lawnmowers and autonomous vacuum cleaners), an unmanned aerial vehicle (UAV), an autonomous agricultural machine, and an underwater vehicle.

[0074] The system may further include a control unit configured to execute the implementation and thereby realize autonomous behavior of the system, which may be verified by method 100.

Claims

1. 1. A computer-implemented method (100) for verifying autonomous behavior of an at least partially autonomous system, comprising: The autonomous behavior is based on the implementation of a behavior tree (10), The method (100) comprises: - translating (120) said behavior tree (10) or another representation of said behavior tree (20) into a Petri net (30a, 30b, 30c, 50, 60, 70); - checking (140) said autonomous behavior based on said Petri net (50, 60, 70), thereby generating test results; A method (100) comprising:

2. checking 140 the autonomous behavior includes checking whether or to what extent the autonomous behavior is intended by one or more requirements for the autonomous behavior; The method (100) of claim 1.

3. checking (140) the autonomous behavior comprises applying a model checker, optionally a probabilistic model checker, based on the Petri net (50, 60, 70); 3. The method (100) of claim 1 or 2.

4. The method (100) comprises: - indicating (141) that the autonomous behavior has been verified if the test result is positive, and / or If the test result is negative, indicating that the autonomous behavior has not been verified and / or that the autonomous behavior needs to be adjusted (142). The method (100) of any one of claims 1 to 3, comprising:

5. The Petri net (50, 60, 70) is functionally equivalent or sufficiently functionally equivalent to the behavior tree (10). The method (100) of any one of claims 1 to 4.

6. Translating (120) the behavior tree (10) or the alternative representation (20) of the behavior tree into the Petri net (50, 60, 70) comprises: - translating (121) one or more nodes (11, 12, 13, 14, 15, 16, 17, 18, 22, 25, 26, 27, 28) of the behavior tree (10) or the alternative representation (20) of the behavior tree into corresponding Petri subnets (40a, 40b, 40c, 40d); - assembling (125) one or more of the Petri subnets (40a, 40b, 40c, 40d) based on the behavior tree (10) and / or the alternative representation (20) of the behavior tree, thereby generating the Petri net (50, 60, 70); The method (100) of any one of claims 1 to 5, comprising:

7. Translating (121) the one or more nodes of the behavior tree (10) or the alternative representation (20) of the behavior tree into corresponding Petri subnets comprises: - translating (122) one or more execution nodes (12, 15, 16, 17, 18, 22, 25, 26, 27, 28) of the behavior tree (10) or the alternative representation (20) of the behavior tree into a first template Petri subnet (40a); and / or Translating (123) one or more control flow nodes (11, 13, 14) of the behavior tree (10) or the alternative representation (20) of the behavior tree into a second template Petri subnet (40b, 40c). The method (100) of claim 6, comprising:

8. The method (100) comprises: optimizing one or more Petri subnets (126) based on meta-information about the at least partially autonomous system, the environment of the at least partially autonomous system, and / or the behavior tree (10) or the alternative representation (20) of the behavior tree; 8. The method (100) of claim 6 or 7, comprising:

9. The method (100) comprises: optimizing (110) the behavior tree (10), thereby generating the alternative representation (20) of the behavior tree (10); Including, Optionally, the alternative representation (20) of the behavior tree (10) is an execution flow graph resulting from removing one or more control flow nodes from the behavior tree (10). The method (100) of any one of claims 1 to 8.

10. The method (100) comprises: optimizing (130) said Petri net (50, 60); The method (100) of any one of claims 1 to 9, comprising:

11. The method (100) comprises: Adjusting (150) the behavior tree (10) or the alternative representation (20) of the behavior tree based on the test results. The method (100) of any one of claims 1 to 10, comprising:

12. The method (100) comprises: Repeating (160) the method (100) according to any one of claims 1 to 11. The method (100) of any one of claims 1 to 11, comprising:

13. A computer system configured to perform a computer-implemented method (100) for verifying the autonomous behavior of an at least partially autonomous system according to any one of claims 1 to 12.

14. A computer program configured to perform a computer-implemented method (100) for verifying the autonomous behavior of an at least partially autonomous system according to any one of claims 1 to 12.

15. 15. A computer readable medium or signal storing or encoding a computer program according to claim 14.

Images