# Scenario Optimisation and Sensitivity Analysis for Safe Automated Driving Using Gaussian Processes
## 5 Method for Scenario Optimisation and Data Acquisition through Simulation
### Methodology for Scenario Optimisation  
After showing the efficacy of modelling logical scenarios using GP models in Reference [8], a logical next step is to optimise the validation process towards only simulating concrete scenarios that are most critical. The parameter space of the logical scenario described in Section 6.1 includes parameter combinations which could lead to less interesting concrete scenarios. These include, for example, the concrete scenarios, where the pedestrian crosses the road long before the ego vehicle reaches the intersection point or on the contrary, where the pedestrian crosses the road after the ego vehicle has passed. These concrete scenarios are not particularly interesting for a validation of the AV, as no direct interaction or conflict arises. In the following, we present a method to optimise the parameter space of the logical scenario to find the critical concrete scenarios that were determined by evaluating the TTC measure as outlined in Section 5.2. We apply a two-stage GP approach for a given logical scenario, consisting of GPC and GPR models as defined in Section 3. Firstly, an initial data set \(\mathbf{\mathcal{D}_{I}}=\{(\mathbf{x}^{I})\}\) of concrete scenarios is created from the definition of the selected logical scenario. Since it is desired to evenly cover the entire parameter space of the logical scenario, the LHC approach as described in Section 5.2 was chosen as the optimised design to generate \(\mathbf{\mathcal{D}_{I}}\). The corresponding outputs (\(y^{I}\)) to the concrete scenarios are then determined by computing the criticality measure of each concrete scenario as described in Section 5.2. The initial data set augmented by the computed outputs, \(\mathbf{\mathcal{D}_{I}}=\{(\mathbf{x}^{I},y^{I})\}\), is converted into a classification data set \(\mathbf{\mathcal{D}_{C}}=\{(\mathbf{x}^{c},y^{c})\}\) where the superscript \(c\) stands for classification, and a data set \(\mathbf{\mathcal{D}_{R}}=\{(\mathbf{x}^{r},y^{r})\}\), which is used for regression modelling, thus the superscript \(r\). For \(\mathbf{\mathcal{D}_{C}}\), the output or label (\(y^{c}\)) of each concrete scenario instance is binary, describing whether the concrete scenario has a valid TTC (\(y^{c}=1\)) or not (\(y^{c}=0\)). This is done in order to filter out scenarios where the pedestrian crosses the road far ahead or behind the ego vehicle, as previously described. Such concrete scenarios would not have a valid TTC, as either Equation (21) cannot be reasonably evaluated, or the TTC is obstructively large and thus not of interest. Furthermore, \(\mathbf{\mathcal{D}_{R}}\) is then the subset of the concrete scenarios in \(\mathbf{\mathcal{D}_{C}}\) with label \(y^{c}=1\), but the output (label) of the \(\mathbf{\mathcal{D}_{R}}\) data set, \(y^{r}\), is the actual minimum TTC score as calculated by Equation (21). These two data sets are then used in the two-staged GP approach, as described in Algorithm 1. Further inputs to Algorithm 1 are the total number of newly generated, critical scenarios \(N\), the number of candidates used in each iteration \(n_{cand}\), and the target TTC measure \(ttc_{target}\).