# Embedded Bayesian Network Contribution for a Safe Mission Planning of Autonomous Vehicles
## 5 Study Cases
### BN Generation Examples
#### 5.1.3 Example 3 Resource-Aware Monitoring for the Tracking Application  
The performance of an application depends on its implementation. For instance to be able to achieve 150 frames per second (FPS) for the tracking application, we need a parallel version implemented with FPGA hardware resources. For each embedded application, different variants can be defined to fit the performance needs. For the tracking application, we can have for instance a fast version (version \(A\)) of 150 FPS that runs on FPGA using all resources, a slow one (version \(C\) at 5 FPS) that runs on \(CPU\) only, and an intermediate one (version \(B\) running at 50 FPS) that runs a the \(CPU\) with a coprocessor implemented on the FPGA. In this section, we show how we can enrich the \(HM\) to take into account the resource constraints of the system and the performance constraints.  
First, the resource constraints are introduced into the \(HM\) as BN nodes. The probabilities of these nodes correspond to the load of the device chosen to execute the embedded applications. A large panel of computing resources can be considered such as GPU, multi-cores FPGA, or heterogeneous architectures such as FPGA-SoC. The resource constraints can be roughly expressed in terms of number of cores for multi-core CPU, number of workgroups for a GPU and in terms of number of tiles (predefined dynamically reconfigurable area) for the FPGA. In a case of hybrid devices like FPGA-SoC (e.g., Altera Cyclone V, Xilinx Zynq), we define the metric \(U_{App_{i}}\) corresponding to the resource occupancy for one application \(App_{i}\), where the fractional part of \(U_{App_{i}}\) represents the \(CPU\) load and where the whole part of \(U_{App_{i}}\) represents the \(FPGA\) load in terms of tiles.  
These two loads (\(FPGA\) and \(CPU\)) can be separately modeled with two different nodes in the \(HM\) whose number of states depends on the parallel grain chosen for each support. For instance, in a case of the \(FPGA\), the number of states can be associated to the number of tiles; and in a case of \(CPU\), the number of states depends on the different interesting thresholds for the \(CPU\) use (typically 20, 40, 60, 80%). Figure 21 illustrates the insertion of this resource constraint into the resource nodes. In this example, we consider a FPGA-SoC device and two resource nodes are inserted. A total of 4 tiles are under consideration for the \(FPGA\), and two thresholds (at 30% and at 80%) for the \(CPU\). The values of these nodes correspond to information monitored by the system and based on this information, we estimate the capability of the chosen version to be executed by the device. We estimate two possible states \(ToActivate\) or \(ToDeactivate\) of the version. This estimation is elaborated through the conditional probability tables of the solution nodes of the \(HM\) related to the resources nodes. If we consider the version \(A\) of the tracking, we need to use all the resources of the FPGA, so the activation of this version is possible only if the monitor of system indicates a total availability of the FPGA.