{'fraction_non_alphanumeric': 0.021307766885705053, 'fraction_numerical': 0.0059678983087364, 'mean_word_length': 4.770980977247296, 'pattern_counts': {'":': 0, '<': 1, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Bayesian Approach to Risk-Based Autonomy for a Robotic System Executing a Sequence of Independent Tasks

—Enabling higher levels of autonomy requires an increased ability to identify and handle internal faults and unforeseen changes in the environment. This work presents an approach to improve this ability for a robotic system that is executing a series of independent tasks, such as inspection, sampling, or intervention, at different locations. A dynamic decision network (DDN) is used to infer the presence of internal faults and the state of the environment based on the available measurements. This knowledge is used to evaluate the risk of executing the current task, which is used to evaluate whether the task should be executed or skipped and whether maintenance actions are needed. Evaluating past states given new information is used to identify skipped tasks that should be revisited. The proposed approach is implemented for a drone tasked with contact-based ultrasound inspection of an industrial facil-ity. The drone is able to successfully distinguish between different internal faults and adverse environmental states and act accordingly. The system makes risk-informed decisions based on uncertain knowledge, enabling it to minimize the time usage while minimizing the potential of harming the drone and maximizing mission completion.

such systems include autonomous underwater vehicles, dynamic positioning systems for ships, and autopilots. Today's systems often rely on human operators to monitor them and to manually intervene if necessary [2], [5], [6]. Developing autonomous robotic systems that can operate without direct human supervision can enable a wider range of missions, such as underwater [4] and space [7] operations, where communication is limited, and long-term [8] and multiagent operations [2] that are economically infeasible to continuously and directly monitor.
For a system to operate without direct human supervision, it must evaluate the situation and handle deviations from normal operation [9]. Hagen et al. [6] argued that a system's "ability to sense, interpret and act upon unforeseen changes in the environment and the [system] itself" is vital for achieving a high level of autonomy. These articles [6], [9] have highlighted the need for an autonomous system to understand and act based on its own state and the state of the environment. Based on this need, four requirements are proposed. The first two consider situational evaluation, and the last two consider acting based on this evaluation: 1) The system must be able to identify the state of the environment during execution. 2) The system must be able to identify internal faults during execution. 3) The system must act proactively to avoid failures. 4) The system must act to minimize the consequences of identified faults.
The purpose of this article is to develop a risk-based decision system that fulfills these requirements for a robotic system that is executing a sequence of independent tasks. These tasks can, for example, be inspection, sampling, or intervention by a robot at different locations. This article focuses on high-level decision-making, considering how and if a task should be executed, or if maintenance actions, such as repairing or servicing the system, should be executed instead. It does not consider emergency fault handling.
The environment's effect on a system and the occurrence of a failure are often connected with uncertainty, making it necessary to consider the risk of a task or operation. Risk can be defined as the effect of uncertainty on objectives [10]. Bayesian belief networks (BBNs) model probabilistic relations, making them suitable to model risk. This capability has been demonstrated for evaluating the risk before [11]- [14] and during [15], [16] an operation. BBNs can be used to proactively avoid failure (requirement 3) as demonstrated in Bremnes et al. [17] for autonomous under-ice operations. And can be used reactively to minimize the consequence of failures (requirement 4) as demonstrated in Coombes et al. [18] where a BBN was used to evaluate the risk of emergency landing location for an unmanned aerial vehicle. These works [17], [18] demonstrated a fulfillment of requirements 3 and 4, but did not consider the identification of the state of the environment and internal faults during execution (requirements 1 and 2) A robotic system acting in an uncertain environment must have sensors that enable it to measure the environmental state and the system's own state. Most realworld systems and environments are too complex to perfectly measure all relevant information. Instead, this information can be inferred by using a model. BBNs have been used to identify the presence of faults [19] and their root causes [20] based on available system information. The system dynamics can be modeled with a dynamic Bayesian network (DBN), which enables the model to incorporate information over time to infer the system state [19], [21], [22]. Furthermore, the decisions of the system can be included in the network, which is referred to as a dynamic decision network (DDN). DDNs are extensively used in educational systems [23]- [25] and dialog systems [26], [27] to better understand the state of the user. The user can in these works [23]- [27] be considered as the environmental state that must be inferred. The literature presented in this paragraph [19]- [27] have demonstrated an ability to identify internal faults and the state of the environment, thereby fulfilling requirements 1 and 2.
The previously presented literature demonstrates that Bayesian models can be used to proactively avoid failures, to reactively minimize consequences, and to identify internal faults and the state of the environment. They fulfill parts of the proposed requirements, but not all at the same time. Codetta-Raitari and Portinale [28] fulfilled all four requirements with a DBN model. Their work focused on monitoring the state of the system and environment and executing preventive and reactive recovery actions when needed. In contrast, the present work focuses on decision-making during a mission using a DDN. Moreover, the present work does not model specific scenarios; instead, it models the possible ways task execution can be affected by the state of the environment and internal faults. This makes the modeling process simpler, as one does not need to explicitly model all possible faults, only how the faults affect the system. In many applications, robotic systems are forced to make decisions based on incomplete and uncertain information and thus cannot avoid erroneous or suboptimal decisions. A system should identify these decisions and act to minimize their consequences. Through utilizing new information, past states can be evaluated with higher confidence, thereby revealing suboptimal past decisions. None of the surveyed works considered evaluating past states to counteract the consequences of erroneous or suboptimal past actions.
This article proposes a Bayesian approach for fulfilling the four defined requirements for a robotic system executing a sequence of independent tasks. A top-down approach for building a DDN is presented, which focuses on only modeling states that can be distinguished based on the observations and actions of the system. The DDN is used to evaluate the risk of executing the current task based on its inferred knowledge of internal faults and the state of the environment. A policy is proposed that evaluates if and how the task should be executed and whether maintenance actions should be executed. Past tasks are reevaluated when new information is gathered to consider if the system should reattempt previously failed or skipped tasks. To demonstrate the proposed method, a case study on a multirotor inspection drone tasked with contact-based ultrasound thickness measurements is presented.
The contribution of this paper is twofold. First, an approach for building and using a DDN that enables the system to fulfill the proposed requirements is presented and demonstrated with a case study. Second, the usefulness of evaluating previous tasks, thereby making the system able to correct mistakes, is demonstrated.
The rest of the paper is structured as follows: Section II presents a method for building the DDN before this method is applied to the case study in section III. Simulation results from the case study are presented in section IV. Section V discusses the proposed method in light of the results from the case study, and a conclusion is presented in section VI.

II. METHOD
This section presents the proposed method for developing and using a DDN to make high-level decisions for a robotic system executing a sequence of independent similar tasks. Tasks are considered independent when Fig. 1. Example of a simple DDN with the color coding used in this article. The objective of the task is shown in orange, the state of the failure causes in blue, actions in gray, and measurements in green. Measurements are available for the current time step (t) and previous time steps but not future time steps.
"no task provides a necessary precondition for the fulfilment of another task" [29].
A DDN can be seen as a sequence of connected BBNs, one at each time step, as illustrated in Figure 1. BBNs are directed acyclic graphs where the arcs represent dependencies. Conditional probability tables (CPTs) are used in each node to quantify the probability that the nodes take on a particular state given the state of all nodes it depends on. Bayes theorem is used to evaluate the resulting belief that a node is in a particular state. The connections across time steps in the DDN are modeled in the same way as the connections within a time step. For more information on BBNs and DDNs, see [30], [31].
The method for building the DDN is presented in section II-A. The decision policy is presented in section II-B. It attempts to minimize the expected cost, considering the direct cost and the associated risk of executing different actions. Each decision that has to be made is modeled as a time step in the DDN. In each time step, the risk of executing the current task is evaluated.

A. Building the DDN
This article proposes building the DDN through a topdown approach. The approach aims at only modeling states that can be distinguished by the observations and actions of the robotic system. The following steps are used to build the DDN. Figure 2 shows an example of the resulting network. Step 1 -Describe the operation and system: To build the DDN, a description of the operation and the robotic system is needed. The operational description needs to define the tasks the system should execute and which actions the robotic system can perform. In this article, three types of actions are considered. First, execution actions that execute the tasks should be described. These are associated with a probability of achieving the goal of the task and may lead to losses, which are discussed further in step 2. The execution actions are associated with a direct cost and an indirect cost if a loss occurs. Second, maintenance actions are described that repair or mitigate internal faults in the robotic system. These actions are associated with a direct cost that the system must weigh against the advantage of maintaining the system. Third, the system must be able to skip the current task and continue on to the next task. By skipping the task, the goal of the task will be unfulfilled. The cost associated with not fulfilling the goal is weighed against the expected cost of attempting the task. How these trade-offs are made is discussed in detail in section II-B.
In the description of the robotic system, a description of the available sensors and information from different subsystems, such as a navigation system, is given.
Step 2 -Model relevant objectives: As risk is the "effect of uncertainty on objectives" [10], the relevant objectives must be identified to make risk-based decisions. Two types of objectives are considered: achieving the task goal and avoiding hazards. A hazard is a set of adverse conditions that can lead to a loss [32]. Damages to the robotic system is one example of a loss. Relevant hazards can be identified through different risk analysis methods, such as preliminary hazard analysis (PHA) [33] or system theoretic process analysis (STPA) [32]. A node is introduced in the DDN for every goal and hazard. An example is shown on line L1 in Figure 2 for a case with one goal and one hazard node. These nodes have two states, that indicating whether the objective will be fulfilled on this execution attempt.
Step 3 -Model failure causes: Different failure causes, such as faults in the robotic system and adverse environmental states, can prevent the objectives from being achieved. Not achieving an objective is considered a failure. The failure causes can be identified with a risk analysis; see [32], [33]. Intermediate nodes are introduced to group failure causes that affect the same set of objectives. These are shown on line L2 in Figure  2. These nodes are only introduced if there exist failure causes that affect this combination of objectives.
All failure causes that affect the same objective nodes and that are affected by the same set of actions are grouped together in the network. This is achieved by  introducing an intermediate node for each group. An example is given on line L3 of Figure 2, where action A and action B affect different failure causes. In the example, all "failure causes causing hazard" are affected by the same actions, making the introduction of new nodes unnecessary.
Step 4 -Model measurable failure causes: Measurements may be available that provide information on some of the failure causes represented by the nodes defined in the previous steps. A new intermediate node representing the measurable failure cause is introduced. In addition, an intermediate node representing the failure causes that are not measurable is introduced. An example is given on line L4 in Figure 2, where a measurement exists for one node. Before the measurement itself can be included in the model, the condition of the failure causes must be modeled.
Step 5 -Model the condition of the failure causes The nodes introduced in steps 2 to 4 have two states indicating whether a failure cause will prevent the fulfillment of the objectives. It can be useful to model the state of the failure causes with higher fidelity. This is accomplished by introducing the condition nodes shown on line L5 in Figure 2. The state of the condition nodes can, for example, reflect the probability that the failure cause will lead to a failure. Alternatively, a physical quantity can be used if its relationship to the failure cause is known. This can, for example, be the state of components that wear out or deplete over time and have a higher failure probability when they are significantly worn or depleted, such as batteries.
Step 6 -Model dynamics: The condition nodes introduced in step 5 are connected between time steps, as indicated with the dotted arrow in Figure 2. The CPT of the condition node specifies the probability that the condition transitions from one state to another given the Task independent condi¡on nodes t 0 t 1 t 2 t 3 t 4 Network L1 -L4 Task 0 condi¡on nodes Task 1 condi¡on ndoes Fig. 3. Example of how different task-specific nodes can be connected to the rest of the network at different time steps. "Network L1-L4" refers to line L1 to L4 in Figure 2. Task 0 is connected to the rest of the network at time steps 0, 1, and 3, while task 1 is connected at time step 2.
choice of action. This probability can also depend on whether the objectives were fulfilled, as illustrated with the dotted arrow to the right in Figure 2. Attempting to execute a task may degrade the condition, while maintenance actions may improve it.
Some conditions might be different for each independent task. These conditions can be modeled by introducing an instance of the condition node for each independent task in the operation. The condition nodes are then connected to the DDN at the time steps where their corresponding task is considered. An example of this is given in Figure 3.
Step 7 -Model measurements: In step 4, nodes are introduced to model the failure causes that can be measured before a task is executed. In this step, the measurements themselves are introduced. These should be influenced by the condition of the measured failure causes, as shown in green at the bottom of Figure 2.
After a task execution is attempted, measurements of whether the objective is met may be available. This information enables the system to infer knowledge about failure causes that cannot be measured directly. These measurements are shown in green at the top of Figure 2 Step 8 -Quantification: The CPTs for the nodes that are not influenced by condition nodes can be modeled with Boolean logic [30]. These define for which combination of "failure" inputs the state of the current node will be "failure". The CPTs of the nodes influenced by a condition node translate the condition into a probability that the underlying failure causes will prevent the fulfillment of the objectives on this execution attempt.
For the condition nodes, the probability of transitioning from one state to another must be specified for all actions and outcomes of relevant objectives. Different expert judgment and data-driven approaches exist for CPT quantification [30], [34]. The initial probability that the condition is in a particular state should reflect how often this state is expected in the operation.
The CPTs of the measurement nodes give the probability of measuring the different values given the state of the node that is measured [30]. For the measurement of the condition, the probability that the different condition states result in the different measured values is needed. For the measurements of the objectives, the probability of obtaining the different measured values when the objective is met or not is needed.

B. Decision policy
This section presents a policy for using the DDN to choose an appropriate action. The policy will typically be developed in parallel with the DDN. The policy combines the probability of not achieving the different objectives with their respective consequences such that risk-based decisions can be made. Three strategies consisting of one or multiple actions are considered: 1) move on to the next task, 2) attempt to execute the task once and then move on to the next task, or 3) execute a maintenance action before attempting task execution once and then moving on. The expected cost of each strategy is evaluated, and the first action of the cheapest strategy is executed. After executing the first action of the strategy, the optimal strategy is re-evaluated. If strategy 2 is chosen multiple times in a row, then the system executes the current task multiple times without moving to the next task.
The cost of strategy 1, moving on to the next task, depends on whether the goal of the current task is achieved or not. If the goal is achieved, then there is no cost associated with moving to the next task. If the goal is not achieved, then there is a cost, C G , based on the consequence of not achieving the goal. This is shown in equation (1). More cases can be added if there can be a partial fulfillment of the goal.
Strategy 2 attempts to execute the task, which has a direct cost associated with it, C(e), and may cause hazards. The cost of the hazards, given by the vector C H (e), are based on their consequences, which can vary with the choice of execution action. The probability of the hazard occurring is evaluated with the DDN and denoted by the vector P H . Attempting a task execution might achieve the goal of the task. The probability of achieving the goal is evaluated with the DDN and denoted as P G . If the goal is not achieved, then strategy 2 will additionally contain the cost of moving to the next task. The cost of strategy 2 is shown in equation (2). This cost is evaluated for all possible execution actions, e, that are applicable for the current task. The different execution actions can have different direct costs related to them, can have different costs associated with their consequences, and might evaluate different probabilities in the DDN. Strategy 3 executes a maintenance action before attempting a task execution. The maintenance action can increase the probability of achieving the goal and reduce the probability of hazards occurring. The effect of the maintenance action is evaluated by setting it as the current action in the DDN and then simulating one step forward in time. The evaluated probability of hazards and goal achievement at the next time step in the DDN is then used to evaluate the cost of execution, C 2,m (e). Additionally, the cost of the maintenance action itself must be included. This cost is often quite high but can improve multiple future task execution attempts. The maintenance cost, C(m), is divided by the expected number of executions until maintenance is needed again, N (m). The resulting cost is shown in equation 3 and should be evaluated for all combinations of maintenance (m) and execution (e) actions.
Updating past states given new information might reduce the expected cost of re-attempting previously failed tasks. The system returns to a previously attempted task if the expected cost of executing the task plus the cost of returning to the previous task, C Ret , is lower than the cost of omitting the task, C 1 , as shown in equation (4). A task is reattempted if the visit is warranted for any of the available execution actions. The closest previously attempted task in the sequence that is worth reattempting is attempted first.
Attempting a task before and after maintaining the system will enable the system to identify if the maintenance helped. To encourage this behavior, the policy always chooses an execution action if the current task has not been attempted and if the execution action is cheaper than the move action. If this is not the case, then the cheapest action is chosen.

III. CASE STUDY
In this section, the proposed method is applied to a multirotor drone tasked with industrial inspection. The case study is based on simulation.

Ci
Expected cost of strategy i e An action that executes the current task m An action that maintains the system CG Cost of not fulfilling the goal C(e) Direct cost of executing the task with action e C(m) Direct cost of executing maintenance action m CH (e) Cost of the potential hazards when executing e PH (e) Probability of potential hazards when executing e PG(e) Probability of achieving the goal when executing e C2,m(e) Cost of strategy 2 after maintenance action m is executed N(m) Mean number of executions between failures for maintenance action CRet Cost of returning to a previous task A. Building the network Step 1 -Describe the operation and system: The operation consists of measuring metal surface thickness with an ultrasound sensor mounted on a multirotor drone [35]- [38]. The ultrasound sensor needs a thin gel layer and must be in stable physical contact with the surface of the inspection point for data to be gathered. A large number of points are to be inspected. Every inspection point is considered a task in the proposed method. The system can choose between two different ways of inspecting the surface of the inspection point: a normal inspection and a slower but safer inspection. For each inspection, a small amount of gel is dispensed from a tank mounted on the drone. One maintenance action available to the drone is to refill this tank. Another is to request a full maintenance check where an operator identifies and repairs all faults of the drone. The drone can skip inspection points that are deemed too costly to inspect autonomously. The costs associated with the actions in the case study are based on time use, making the goal of the decision policy to minimize the operation time. The skipped inspection points will have to be inspected manually by an operator, which will extend the operation time. The different costs are discussed in more detail in section III-B.
The drone is equipped with a lidar that can be used for detecting obstacles and for navigation. The navigation estimate can be used to monitor the trajectory of the drone.
Step 2 -Model relevant objectives: The goal of each task is to measure the surface thickness of the inspection points. As the drone operates in controlled industrial facilities consisting of metal surfaces without any human beings present, the most relevant loss is damage to the drone. A hazard that can lead to this loss is uncontrolled contact with a surface or other object. The two objectives, "gathering data" and "avoiding uncontrolled contact", are introduced as shown on line L1 in Figure  Data

4.
Step 3 -Model failure causes: Some failure causes, such as an empty gel tank, rust or dirt stuck on the ultrasound sensor, or inspection surfaces covered with rust or dirt, can prevent data from being gathered. Other failure causes, such as a worn motor, poor navigation quality, or obstacles, can lead to uncontrolled contact in addition to preventing data from being gathered. No failure causes are considered that lead to uncontrolled contact but do not prevent data from being gathered. Two intermediate nodes are introduced: one for failure causes preventing data from being gathered, and the other for failure causes preventing controlled contact and data from being gathered.
The drone and the surface of the inspection point are affected by different actions. Executing an inspection may damage the drone, while the surface will not be affected. Similarly, maintaining the drone does not affect the surface. Moving to a new inspection point will change the surface but not affect the drone. A distinction between drone-related and surface-related nodes is therefore needed. Furthermore, the refill-gel action will only affect the gel level. The gel level does not affect the ability to avoid uncontrolled contact. Lines L2 and L3 in Figure 4 show the resulting nodes and their connections.
Step 4 -Model measurable failure causes: Before an inspection is executed, part of the surface-related failure causes that prevent controlled contact and data gathering is measured with the lidar. The lidar scan of the surface can reveal the presence of protruding obstacles that will prevent controlled contact and data gathering. Separate nodes are introduced for the failure causes that are measurable and those that are not, as shown on line L4 in Figure 4. This makes it possible to distinguish between failure causes that are measurable with the lidar and those that are not. The unmeasurable failure causes can, for example, be minor surface irregularities, such as welding joints, that are typically missed by lidar beams. Other measurements, such as navigation quality, could be included if desirable.
Step 5 -Model the condition of the failure causes A slightly dirty or uneven surface, or a small fault in the drone, can reduce the likelihood of an inspection succeeding without hindering it completely. The states of the condition nodes, for all nodes except the "gel level" node, reflect the average frequency at which the respective conditions will cause a failure. These frequencies are discretized into different states, as shown in Figure 4. The DDN is used to evaluate the probability distributions over these states. The state of the gel level indicates the amount of gel left. When the gel level approaches zero, an insufficient amount of gel might be deployed. This will prevent data from being gathered.
Step 6 -Model dynamics: There is a probability of introducing drone-related failure causes with each inspection attempt. The probability and severity will depend on whether uncontrolled contact occurred and whether a normal or safe inspection is performed. The gel level decreases with each inspection and is unaffected by the occurrence of an uncontrolled contact and the choice of inspection action.
Surface-related states are independent for each inspection point and are handled as discussed in section II-A step 6 and illustrated in Figure 3. The condition of the surface is assumed to be constant for each inspection point.
Step 7-Model measurements: The "surface suitability measurement" is introduced as shown at the bottom of Figure 4. The measurement is based on how flat the area around the inspection point seems based on the lidar scan. The suitability is discretized into four distinct states ranging from poor to perfect.
After an inspection is executed, a measurement of how the execution went is needed. Whether data is successfully gathered is readily available from the ultrasound thickness sensor. Whether an uncontrolled contact occurred cannot be directly measured. Instead, this can be inferred based on the trajectory conformity measure. This measurement is made by comparing the observed trajectory of the drone with the intended trajectory and identifying any deviations in position, velocity, and heading. This measurement is also discretized into four states ranging from poor to perfect based on data from the drone's navigation system.
Step 8 -Quantification: The CPTs are shown in Figure  4 and Tables II, III, IV, and V. The initial probability distribution over the state for the different surface condition and drone condition nodes can be found in Tables II and III. Tables IV and V show the probabilities of transitioning to a worse state for the different drone condition nodes when an inspection is attempted. The probability of transitioning to a better state is zero, as it is assumed that the drone cannot accidentally repair itself. When evaluating the new probability distribution based on Tables IV and V, transitions that lead to negative states are omitted, and the resulting distribution is normalized such that it sums to 100%. The condition of the drone can only be improved by maintenance actions. The refill gel action will set the gel level to 100%. The full maintenance action sets all drone-related nodes, including the gel level, to their initial distribution. The numerical values presented in this section are selected to showcase the algorithm. They are not based on operational data.

B. Decision policy
The decision policy presented in section II-B is used in this case study. The values of the different parameters are shown in Table VI. These costs are based on the expected time use. The expected time use of an uncontrolled impact is based on the expected time needed to repair the different degrees of damages that can occur times the likelihood of them occurring from an uncontrolled impact. The cost of not achieving the goal is based on the additional time used for a manual inspection.

IV. RESULTS
This section presents four scenarios for the inspection drone case study. These scenarios were chosen because they demonstrate different aspects of the method and represent failures that are deemed likely to occur. The scenarios are simulated in Python using the SMILE [39] library to evaluate the DDN. In each scenario, the measurements that the system will experience are specified for each inspection point. The actions that the drone chooses and the drone's belief regarding relevant A. Scenario 1 The first scenario demonstrates the system's ability to identify the cause of a failure based on the observed behavior and the ability to reason over past states. In this scenario, the ultrasound thickness sensor is not working, making all inspections end with no data being gathered but perfect trajectory conformity. Figures 5,  6, and 7 show how the belief of the system develops over time when new inspections are attempted and new information is gathered. Only the belief that dronerelated and surface-related failure causes will prevent data gathering is shown. The rest of the nodes have a belief close to 0 throughout this example. Figure 5 shows the behavior and beliefs of the drone when it is at the first inspection point. As seen in the table in Figure 5, the drone attempts to execute an inspection, which results in no data but perfect trajectory conformity. After the first inspection fails, the belief that surfacerelated failure causes prevent data from being gathered increases. The belief that drone-related failure causes prevent data gathering also increases but much less. The reason is that it is more probable that a single failed inspection is caused by the surface than the drone. This trend continues for the subsequent inspection attempts. At time step 3, the belief that surface-related failure causes will prevent data gathering is high enough to make the drone skip the current inspection point and move on to inspection point 1.
The broken line in Figure 5 shows the system's belief about past states evaluated at time step 3. The surface is modeled as static, making the belief about its past state equal to the newest belief. The updated belief for the drone-related failure causes preventing data gathering at time step 0 is higher than it was initially but not as high as in time step 3. This is because there is a probability, although low, that the drone was damaged in one of the previous inspection attempts. Figure 6 extends Figure 5 by showing 11 time steps. At inspection point 1, the same behavior is observed as at inspection point 0. After three failed attempts, the system skips this inspection point and moves on to inspection point 2. When evaluating the past states at time step 7, shown as the orange broken line, the probability that the drone-related failure causes are preventing data gathering has increased. The probability that a drone-related failure cause was introduced in one of the last time steps is low, making it probable that if there is a drone-related failure cause at time step 7, then there was probably one in the earlier time steps as well. Since the belief that drone-related failure causes prevented data gathering in time steps 0-3 has increased, the belief that the surfacerelated failure causes of inspection point 0 prevent data gathering decreases. This can be seen by the orange broken line being lower than the blue broken line at time step 0-3 for the surface-related failure causes.
After failing an inspection at inspection point 2 as well, the belief that the drone-related failure causes are preventing data gathering is high enough, making full maintenance worth the cost. After maintenance, the next inspection at time step 10 is successful. This shows that inspection point 2 can be inspected, which decreases the likelihood that there are surface-related failure causes preventing data gathering. This in turn increases the likelihood that drone-related failure causes prevents data gathering at time step 8. Evaluating backwards in time, the probability that drone-related failures caused the previous failed inspection attempts increases. This in turn reduces the belief that there are surface-related failure causes that prevent data gathering at inspection points 0 and 1, as shown with the green broken line in Figure 6.
When considering where to go next, the system will evaluate whether revisiting a previously visited inspec-      tion point is worth another inspection attempt. Since the belief that the surfaces on these inspection points caused the failures decreased, the system concludes that they are worth revising. As shown in Figure 7, the system first visits inspection point 1 again, where data are gathered successfully. This further strengthens the belief that there are no surface-related failure causes preventing data gathering at inspection point 1. This increases the belief that the failed data gathering attempt was related to the drone the last time inspection point 1 was visited. This in turn increases the belief that the drone-related failure causes were present the last time inspection point 0 was visited as well. This in turn decreases the belief that there are failure causes related to the surface at inspection point 0, as shown by the pink broken line in Figure 7. The system then returns to inspection point 0 and has a successful inspection before moving on to a new inspection point.

B. Scenario 2
This scenario demonstrates how the risk of damaging the drone affects the behavior. The drone is in a condition such that it cannot establish good contact with the surface. All inspections result in data not being gathered and a medium path conformity. The belief that drone-related and surface-related failure causes prevent data gathering and that drone-related and unmeasurable surface-related failure causes prevent controlled contact and data gathering is shown in Figure 8. The rest of the nodes have a belief close to zero throughout this scenario.
In this scenario, the drone does not attempt to inspect the inspection point again after the failed inspection attempt at time step 0, as shown in Figure 8. This is due to the large cost associated with the possibility of having uncontrolled contact if the inspection is reattempted. At inspection point 1, a safe inspection action is performed since there is a considerable probability that the failure at time step 0 was caused by the drone. The system attempts one last inspection at inspection point 2 before executing full maintenance. After maintenance, the belief that there are drone-related failure causes preventing controlled contact, and data gathering is close to zero. In the next time step, a safe inspection is executed since the failure might have been caused by the surface, which was unaffected by the maintenance action. Since the inspection was successful, the belief that there were surfacerelated failure causes preventing controlled contact, and data gathering at inspection point 2 decreased. When evaluating backward in time at time step 5, as shown by the green broken line, the belief that drone-related failure causes prevents controlled contact and data gathering at time steps 0 and 2 is significantly increased. This decreases the belief that the failed inspection was caused by surface-related failure causes, making a revisit worth its cost. A safe inspection is performed at inspection point 1, as there could still be surface-related failure causes at this inspection point. 13 Time

C. Scenario 3
This scenario demonstrates how the surface suitability measurement affects the choice of actions. Figure  9 shows how the system decides to not attempt an inspection if the surface suitability measurement is poor. With a medium surface suitability measurement, a safe inspection is attempted, but the system only attempts one inspection. When the surface suitability measurement is good but not perfect, two inspection attempts are warranted before moving on.

D. Scenario 4
This scenario demonstrates the effects of the gel level node. Figure 10 shows the expected value of the gel-level node in addition to the belief that gel-level-related failure causes prevent data gathering to better show how the gel depletes over time. The figure starts after 12 successful inspections. With each inspection, the expected gel level decreases. The belief that the gel-level-related failure causes prevent data gathering first starts to increase when the belief that the gel level is close to depleted increases. When no data is gathered in the inspection attempt at time step 37, the drone assumes it is caused by a low gel level, and a refill is therefore executed.  V. DISCUSSION Scenario 1 shows that the system is able to distinguish between faults with the drone and adverse inspection points by combining information over time. This enables the system to reactivity handle faults by executing maintenance actions when needed, even though the information available to the system from a single inspection attempt is insufficient to identify the cause of the failure. Furthermore, this scenario demonstrates that reasoning backward in time enables the system to realize that the previously visited inspection points were not the cause of the failure. This enables the system to reactively handle failure in achieving the mission objective by returning the previously failed tasks.
Scenario 2 shows that the system is less willing to attempt multiple executions when there is a high probability of uncontrolled contact. After the first uncontrolled contact, the system executes a safe inspection action even though it has moved to a new inspection point. This shows that the system acts proactively to minimize the risk of damage, as there was a chance that the failure was caused by the drone. Scenario 3 demonstrates that the system considers the measurements available before the task execution and acts proactively to avoid losses. Scenario 4 demonstrates how the gel-level node affects the behavior. In scenario 1, the system does not believe that the failed inspections are caused by the gel level, as the failure occurs immediately after take-off. In scenario 4, many inspections were successfully performed before the execution failed, making it probable that the gel was depleted.
These scenarios demonstrate that re-evaluating past states enables the system to maximize the mission objective while keeping the cost low. The system manages to fulfill the feasible tasks without having to unnecessarily maintain the system. The resulting system is not able to directly identify the cause of the observed behavior. When there is a high belief that drone-related failure causes prevent data gathering, the system does not know what the failure cause is. It could be anything preventing the drone from gathering data at multiple inspection points that does not affect the motion of the drone. The sensor could be displaced, there might be some dirt on the sensor, or the sensor might be wrongly calibrated or not suitable for the current mission. Which of these scenarios is true is irrelevant, as they all prevent data from being gathered and have the same solution: requesting human assistance. The advantage of this approach is that the system does not need a model of all possible causes but rather a model of the different ways the task execution can be affected by failure causes.
One of the advantages of Bayesian models is that they can be based on expert judgment in addition to experimental data. This enables the models to be used on novel systems where operational data is missing. Quantification of CPTs based on expert judgment is not a trivial task, and many different methods exist to simplify the process [30]. This article simplifies the process by using Boolean operators for most of the network. This reduces the number of nodes that require further quantification to the condition and measurement nodes. This has the advantage of reducing the number of model parameters that must be determined and enables the evaluation of each parameter in isolation. A challenge with this approach is that it is not clear from the network which failure causes that should be considered when quantifying the CPTs. A hazard analysis can be performed to identify these causes [32], [33], which can help with quantification.
The main drawback of this method is with regard to computational time. Evaluating large networks can in some cases be done very quickly (<1s) with the exact solution from the SMILE [39] library. However, for some models and some sequences of evidence, the computational time can suddenly become very large or the problem can become unsolvable for the exact solver. Slightly different models or different evidence can require substantially different computational times. Which models and scenarios that are problematic are not easy to identify in advance. The SMILE library also includes several approximate sampling-based algorithms that have more stable computational time and can handle all models and evidence. The execution time of the approximate algorithms are substantially longer than the exact solution for simple problems but does not increase significantly for complex problems. The precision of the approximate algorithms can be adjusted to reduce the computational time. As the network only needs to be evaluated every time a task is considered, a computational time of a few seconds can be acceptable. Using the proposed method online seems to be feasible, but more work is recommended on optimizing the algorithm for online use.

VI. CONCLUSION
This article presents an approach for building a DDN for decision-making for an autonomous robotic system executing a sequence of independent tasks. A case study on drone inspection demonstrates that the system is able to identify internal faults, such as sensor defects, and the state of the environment, such as unmeasured obstacles. The system manages to act proactively to avoid potential losses and acts reactively by maintaining the system and revisiting failed inspection points when needed. The proposed method thereby demonstrates the fulfillment of the four requirements proposed in the introduction.
This work has demonstrated that evaluating past states is a useful tool when considering a sequence of tasks. Due to the limited information available at a single task, the system might make suboptimal decisions, such as skipping the task when a maintenance action is instead needed. When updating the belief of past states with new information, better estimates can be made. This enables the system to identify that it should reattempt a previously skipped task, thereby achieving a higher degree of mission goal fulfillment.
The goal of this article is to contribute to more autonomous robotic systems that do not require direct human supervision. The case study demonstrates an increased ability to identify and act upon internal faults and the state of the environment beyond direct sensor measurements. This indicates that the proposed method provides the system with part of the autonomy that is needed to operate without direct human supervision. The method still needs experimental validation.
In addition to experimental validation, further work could explicitly model the consequences of actions and the quality of the measurements. The use of continuous probability functions instead of discrete states is also considered for further work.