Context-dependent reconfiguration of autonomous vehicles in mixed traffic

Context-dependent reconfiguration of autonomous vehicles in mixed traffic José Miguel Horcas1Julien Monteil2Mélanie Bouroche2Mónica Pinto1 Lidia Fuentes1Siobhán Clarke2 1CAOSD Group, Universidad de Málaga, Andalucía Tech, Spain 2Distributed Systems Group, School of Computer Science and Statistics, Trinity College Dublin, Ireland Correspondence José Miguel Horcas, Bulevar Louis Pasteur, 35. ETSII Lab. 3.3.3, Campus de Teatinos, Malaga 29071, Spain. Email: [email protected] Funding information Magic, Grant/Award Number: P12-TIC1814; HADAS, Grant/Award Number: TIN2015-64841-R Abstract Human drivers naturally adapt their behaviour depending on the traffic conditions, such as the current weather and road type. Autonomous vehicles need to do the same, in a way that is both safeandefficientintraffic composed of both conventional andautonomousvehicles.Inthispaper, we demonstrate the applicability of a reconfigurable vehicle controller agent for autonomous vehicles that adapts the parameters of a used car-following model at runtime, so as to maintain a high degree of traffic quality (efficiency and safety) under different weather conditions. We follow a dynamic software product line approach to model the variability of the car-following model parameters, context changes and traffic quality, and generate specific configurations for each particular context. Under realistic conditions, autonomous vehicles have only a very local knowledge of other vehicles' variables. We investigate a distributed model predictive controller agent for autonomous vehicles to estimate their behavioural parameters at runtime, based on their available knowledge of the system. We show that autonomous vehicles with the proposed reconfigurable controller agent lead to behaviour similarto that achieved by human drivers, depending on the context. KEYWORDS autonomousvehicles,car-followingmodel,dynamicsoftwareproductline,reconfiguration,traffic quality 1INTRODUCTION Drivers' behaviour often changes during a journey because of several environmental factors such as the typology of the roads (motorways, high speed roads, arterials, and local streets), the type of road surface (asphalt, concrete, and gravel roads), and weather conditions (dry, rain, and snow). A human driver takes into account all these factors and adapts his or her driving style accordingly.1 In mixed-traffic environments, ie, where autonomous vehicles share the roads with conventional vehicles, autonomous vehicles should also adapt to these contextual changes but without deteriorating traffic safety and efficiency, as autonomous vehicles' behaviours that are overly different to human driven vehicles might lead to hazardous and chaotic situations.2The behaviour of an autonomous vehicle will be altered at runtime by modifying/reconfiguring the parameters of the car-following model (eg, desired speed, desired time headway, acceleration, and braking) or even by changing the model itself (eg, the car-following model or the lane-changing protocol). For instance, lane-changing handlers in charge of controlling vehicles on motorways mostly rely on minimising decelerations (eg, the MOBIL model3), whereas a lane-changing handler in urban traffic relies on the allocation of vehicles' neighbours and the management of conflict areas (eg, the Vertigo model4). In any situation, the dynamic selection of the most appropriate set of model and parameters must help to increase traffic-flow safety and efficiency. However, the literature has just started to investigate the applicability of various car-following models under varying environmental contexts such as adverse weather conditions.5,6Driving scenarios (eg, highways, intersections, and roundabouts for dry roads) are usually studied separately, and as a result, emerging control systems do not consider contextual changes of scenarios, while real-world driving involves mixing different scenarios on the same route. Moreover, the parameters values for an autonomous vehicle controller are specific to each context and need to be taken into account at runtime: If no behavioural change is introduced, the sudden appearance of adverse weather conditions will cause autonomous vehicles to have unsafe time headways, and the sudden improvement of weather conditions will cause autonomous vehicles to be overly cautious, having a detrimental effect on traffic efficiency. Car-following models, which can be collision-free or collision-prone, time continuous or time delayed, incorporate a high degree of behavioural variability in the longitudinal dynamics. Their behavioural parameters (desired speed, desired time headway, maximum acceleration, jam distance, etc) depend on the vehicle characteristics and the driving style and are context-dependent. The impact of behavioural parameters on traffic safety and efficiency under specific weather conditions can be assessed via traffic quality indicators (mean speed, total time spent in the network, local densities, time to collision, etc). In this paper, we demonstrate the applicability of a vehicle controller agent for autonomous vehicles that is adaptive to contextual changes, embodied by changes in weather conditions (dry conditions, light rain, and heavy rain). The controller agent automatically reacts to changes in the context by reconfiguring the behavioural parameters of the car-following model used, to maintain a high degree of traffic quality (efficiency and safety) with varying weather conditions. The controller agent has been developed following a dynamic software product line (DSPL)7approach, which deals with the high degree of variability in an autonomous vehicle's behaviour, the environmental context, and the traffic quality. Moreover, using a DSPL, our approach generates specific configurations for the vehicle controller agent for each particular context, at runtime. Software product lines (SPLs)8,9are traditionally used to exploit and handle the commonalities and variations of applications in different domains. However, variability in vehicle controllers has not received much attention.6For example, there is no approach that integrates the variability of context changes, a vehicle's behaviour, and the indicators of traffic quality, as part of the variability management of an SPL. The paper is structured as follows. First, in Section 2, we introduce the background information and describe the relationships between weather conditions and the behavioural parameters of car-following models. We also present the challenges we address in this paper. In Section 4, we design an estimate of the ideal behavioural parameters for autonomous vehicles, assuming that autonomous vehicles have full knowledge of the vehicles' positions and speeds in the system of vehicles. Then, in Section 5, we present our reconfigurable vehicle controller. We focus on realistic conditions, whereautonomousvehicles only havepartialinformationaboutthe system variables, and performonlineoptimisationforeachautonomous vehicle within a model predictive controller agent. Section 6 assesses the relevance of our algorithms, and we compute indicators of traffic-flow efficiency (travel time and homogeneity of speeds) and of traffic-flow safety (eg, time to collision and post-encroachment time). We evaluate these indicators with and without reconfiguration, showing the relevance of our approach for increasing the quality of traffic flow. Section 3 discusses previous work in the literature. Finally, Section 7 concludes the paper. 2BACKGROUND INFORMATION AND MOTIVATION In this section, we first introduce common terms relating to autonomous vehicle controllers and car-following models, the main behavioural parameters of car-following models, and their relationships with weather conditions. We also provide a background to DSPLs. Then, in section 2.4, the motivation of our approach is presented as a set of challenges we address in this paper. 2.1 Car-following models and behavioural parameters An “autonomous vehicle controller” is a system with the power and ability for self governance in the performance of control functions of a vehicle undersignificantuncertaintiesinthe environment,without externalintervention, overextendedperiods.10 Thebehaviourof each individual vehicle (“microscopic traffic”) is defined by the traffic model (eg, a car-following model) of the autonomous vehicle controller, to see its implications on the whole traffic system (“macroscopic traffic”). In a “car-following model,” vehicles update their cinematic according to their perception of a leading vehicle's behaviour. There are 2 main types of car-following models: “time continuous” and “time delayed.” Time continuous models relate to empirical models that model the acceleration trajectories of vehicles as a continuous function of time, whereas time delayed models relate to physical models that try to capture reaction times andstimulus-responsemechanisms.Inaddition,car-followingmodels can be “collision-free” or “collision-prone” in the sense that collisions between 2 vehicles (crashes) are prohibited or possible. Our approach is independent of the car-following model used, so it is possible to use any car-following model like the Intelligent Driver Model (IDM),11 theGippsmodel,12 oroptimal velocitywith relativevelocity(OVRV).13 Concretelyinthis paper,wehaveselectedtheIDMmodel because it iscollision-free,it describesshock-wavepatterns andany othertrafficregimevery well,anditis identifiable(thesameset ofbehaviouralparameters can describe the behaviour of one driver in different traffic regimes). For these reasons it is one of the most robust existing car-following model, and very suitable for our analysis. Moreover, depending on the traffic conditions, the autonomous vehicles may use a different car-following model. For instance, the Gipps model can be more appropriate in the event of car accidents, since the Gipps model is specially designed to prioritise safety over efficiency,12 while the OVRV model is more appropriate to suppress traffic jams and increase traffic capacity.13 Car-followingmodelshavealotofconfigurableparametersthatdeterminethe behaviouroftheautonomousvehiclessuchasspeed,acceleration, deceleration, time headway, and jam distance. As our objective is to provide a vehicle controller that is adaptive to contextual changes, we focus on the relationship between car-following models parameters and different weather conditions, in particular on rainy adverse conditions. The main parameters that affect the behaviour of autonomous vehicles to environmental changes are speed (v), the desired safe time headway (Th), and the maximum tolerated acceleration (acc)—see Section 3. The time headway is the time that elapses between the arrival of the leading vehicle and the following vehicle at a designated point. The tolerated acceleration is the maximum acceleration that is tolerated by the driver/vehicle in a particular environmental context. 2.2 Relationships between car-following behavioural parameters and weather conditions It was recently shown in Monteil et al14 and Punzo et al15 that, under dense traffic conditions with speeds (eg, around 17 m/s in highways) that are far enough from the desired speeds (ie, the maximum speed limit, here, 33 m/s), only 2 parameters are sensitive and therefore need to be estimated: the desired time headway Th and the maximum tolerated acceleration acc. These 2 parameters are therefore the parameters we will consider for reconfiguration at runtime in this paper. We make use of the NGSIM dataset (Next Generation Simulation of Traffic Analysis Tools Program)*to build real assumptions about how the parametersTh andacc canvary underdifferentweather conditions.We getfittedvaluesfor Th andacc fromtheNGSIM dataset,by filteringthedata, and by fitting each observed trajectory data with car following–based simulated trajectory data reacting to the leading vehicles' trajectory data. Then, once we have estimated values for the 2 parameters, we consider that those parameters are impacted by weather conditions in the following way, in accordance with the literature (see Section 3). The desired time headway is computed for light rain conditions with an expected variation of 50% and with an expected variation of 180% for heavy rain conditions; the maximum tolerated acceleration is computed for light rain conditions with a expected variation of 10% and with an expected variation of 45% for heavy rain conditions. We are aware that these are strong hypotheses to be introduced, but they enable the approximation of realistic behaviours, and therefore, the controllers to be reconfigured are considered to be close enough to the observed real traffic situations. 2.3 DSPLs and adaptive traffic behaviour An SPL is “a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.”9The SPLs' engineering process is in charge of generating several configurations of the same system at design time. A DSPL brings this engineering process to runtime, where a single system is able to adapt its behaviour at runtime. 7,16 “Variability modelling” is the main activity of both SPLs and DSPLs, where the commonalities and variabilities of the system are specified. Then, the SPL engineering process generates products by selecting specific characteristics specified in the variability model. In an SPL, the software engineer binds the variation points to the software architecture at design time, considering the requirements of the intended system. The “software architecture” defines the components that model the behaviour of the application and that communicate with each other using connectors.17 The variable parts of the software architecture are explicitly specified in the variability model at an abstract level. In a DSPL, the variability model describes the potential range of variations that can be produced at runtime for a single system—ie, the dynamic variation points. Therefore, the software architecture supports all possible adaptations defined by the set of dynamic variation points.7 In the context of the adaptive traffic behaviour, as part of the DSPL, the engineer must define (1) the variability of the car-following models (eg, all configurable parameters) and the variability of the traffic context and the traffic quality indicators; (2) the range of potential adaptations supported by the system in terms of architectural components, ie, the software architecture of the autonomous vehicles; (3) the context changes that may trigger an adaptation, ie, the criteria to initiate a reconfiguration or decision making process (eg, a change in the weather conditions); and (4) the set of possible reactions to context changes that should be supported the system (eg, change the acceleration and time headway parameters). 2.4 Challenges This subsection describes the main challenges to be addressed in the development of our reconfigurable controller agent. Here, we introduce an approach to address each challenge as well as the reason for using a DSPL. Challenge 1. To model and manage the variability of the autonomous vehicles' behaviour and of the traffic context. As previously discussed, car-following models present a high degree of variability. They are based on different factors such as the vehicle's characteristics and driver's behaviours; can be collision-free or collision-prone, with orwithoutexplicittime-delays;anddependonparameters whose values dependonthe context: desired speed, desired time headway, maximum acceleration, jam distance, among others. Moreover, the traffic context also presents a high degree of variability that can change at runtime. Real-world driving mixes different kinds of roads along the same route (eg, motorways, local streets, and roundabouts), traffic density (eg, jams and traffic flow), and adverse conditions (eg, rain and snow). Modelling this variability also implies having to model the existing relationships between the different parameters. Our approach: we identify the parameters of a vehicle's behaviour and of the car-following models that are suitable for reconfiguration and explicitly model their commonalities and variabilities. We alsomodel the variability presented in the traffic context (eg, weather conditions, road type, and road topology). To model the variability, we use the common variability language (CVL),18 which is a domain-independent language for specifying and resolving variability over different models, and allows defining the links between the variability specification (features) and the assets (components, parameters, etc) of the product line—ie, the software architecture of the autonomous vehicle (section 5.1). *http://ops.fhwa.dot.gov/trafficanalysistools/ngsim.htm Challenge 2. To automatically change the behaviour of the vehicle when the current traffic context changes. The core behaviour of the vehicles depends on the context. For instance, on motorways, a car-following model or a lane-changing handler is usually in charge of controlling the vehicle (eg, IDM model and the minimizing overall braking induced by lane change (MOBIL) model), but for urban traffic, the controller handler may rely on allocation of the neighbours and managing conflict areas (eg, the Vertigo model). Additionally, the behaviour of the vehicles is also affected by adverse conditions like rain. These kinds of context changes require the vehicle behaviour to be adapted—eg, adapting the car-following behavioural parameters such as acceleration and time headway. Our approach: we generate, at runtime, the new configuration of the vehicle software architecture to adapt its behaviour to the current context. To achieve this, we use a DSPL approach that allows us to change the configuration of the parameters that affect the vehicle behaviour at runtime, when the context changes. Indeed, the explicit modelling of the variability of thevehicle behaviour and of the context facilitates reasoning about them and changing them when needed. In this paper, we focus on optimising the behavioural parameters (acceleration and time headway) to provide an optimised behaviour for a particular context. To do so, we define a model predictive controller agent that performs dynamic optimisation for the parameters of each autonomous vehicle, taking into account the knowledge available at runtime (see Section 5.2). Challenge 3. To improve the safety and efficiency of the traffic network when autonomous vehicles are reconfigured.Despite the high degree of variability exhibited in traffic behaviour, the autonomous vehicle controllers need to ensure safety and maintain the traffic-flow quality. Our approach: we use several quality traffic indicators (eg, time to collisions, travel time, and post-encroachment time) to assess safety and efficiency in the trafficnetwork. Weincludethisinformationinthe DSPLtoselectthe mostappropriateindicators toevaluatethetrafficqualitybased onthecurrentcontext. The goal is to demonstrate that autonomous vehicles with our reconfigurable control agent improve the safety and efficiency in mixed-traffic networks. 3LITERATURE REVIEW AND RELATED WORK We present a brief literature review about the effects of weather conditions on vehicles' behaviour. We also compare our approach with existing related work that focus on reconfiguration at runtime using DSPL. 3.1 Effects of weather conditions on parameters Several studies have investigated the influence of weather conditions on driving behaviour: from rain,19-23 to snow,21,24,25 fog,20,24 or even temperature and wind.24 As in this paper we have focused on rainy adverse conditions, we investigated the influence of weather conditions on the behavioural parameter considered: time headway (Th) and acceleration (acc). These are the parameters more affected by adverse conditions.14,15 In summary, as the intensity of rain develops, acceleration is reduced and time headway is increased.26 3.1.1 Effects of rain on time headway. Hogema22 collected the percentage of vehicles with a time headway of less than 1, 3, and 5 seconds and showed the effect of rain: The percentage of vehicles with a mean time headway less than 1 second was smaller than when conditions were dry. Vehicles with a time headway of 3 seconds showed a similar, but smaller effect, while no effect of rain was found for vehicles with a time headway of 5 seconds. Billot et al19 also assessed the rain impact in time headways: A drop of 12.1% of the time headway less than 2 seconds is observed under light rainy conditions, while in heavy rainy conditions, a sharper decrease of more than 18% is observed (a rise of the time headway between 2 and 10 s). Hoogendoorn et al5observed an increase of the time headway from an average of around 1.5 seconds in normal conditions to a very high value of around 3.7 seconds in the adverse weather condition. This is an indication of strong adaptation effects in longitudinal driving behaviour, and the author estimated the values for the IDM model.11 Jung et al27 selected time headway as one of the key weather-sensitive traffic parameters along the free-flow speed and deceleration rates. However,theirresearchonlytakesintoaccounttheadjustmentofthetimeheadway value, changing it from 0.9 seconds (default) to 1.1 seconds under adverse conditions. Soria et al6also predict an increase of the time headway from 0.72 to 1.1 seconds under rainy conditions. 3.1.2 Effects of rain on tolerated acceleration. Few studiesfocus on the particular effects of adverseconditionsontheacceleration behaviourof a vehicle,as the acceleration behaviourof vehicles cannotbeobserved atamacroscopiclevel,likedesiredtime headways orspeeds.Soriaetal6estimatedthat,fortheGippsmodel,12 thedifferentrain conditions resulted in the same maximum acceleration: 3.3 m/s2. However, Hoogendoorn et al5observed that the maximum acceleration decreases substantially with rain conditions: from 1.6 to 0.5 m/s2, for the IDM model. Zhao et al28 also observed that the maximum observed acceleration decreases from 4.36 to 2.50 m/s2under inclement weather. Finally, Asamer et al25 showed that the desired acceleration can be reduced from 10% to 100% by adverse conditions, and in their experiments, acceleration showed a reduction to 71% of original acceleration settings. 3.2 Reconfiguration of vehicle behaviour Two similar reconfiguration approach to ours are presented in Asamer et al25 and in Cetina et al.29 Asamer et al25 propose preselecting several parameters and choosing value ranges for those parameters to deal with the complexity of a large search space when all possible parameters of the car-following model are changed during calibration, and not all the combinations can be evaluated in an acceptable time. Cetina et al29 propose an approach for the design of pervasive SPLs that are reconfigured according to changes in the environment, although they do not focus on changing vehicle behaviour. They use feature models to specify the variability and event condition action (ECA) rules to trigger the reconfiguration process. To cope with the complexity of the variability, the SPL is pruned at design time, removing those model elements that are related to scenarios that are not useful and therefore limit the configuration space. In our approach, in contrast to pruning the SPL, we delimit the possible configurations to be selected by defining Object Constraint Language (OCL)†30 constraints over the variability model. These OCL constraints set the most appropriate parameter/model for each context, as the Asamer approach25 does for the car-following parameters. This makesthegeneration of the configuration in our approach straightforward due to the tree constraints and cross-tree constraints of the variability model. Althoughthe reconfiguration approaches that focus on changing a vehicle'sbehaviour at runtime based on the contextare scarce, there are some approaches for generic reconfiguration at runtime that use DSPL as we do. For instance, Pascual et al31 present a novel approach that provides supportfordynamicreconfiguration,optimising theirarchitectural applicationconfigurationaccordingtotheavailableresources.Even thoughthey focus on mobile applications, they also model the variability of the application's software architecture using SPLs, as we do. The main difference between the 2 approaches is that they take advantage of genetic algorithms to optimally resolve the application's variability, while in our approach, we use a model predictive controller agent to obtain the best parameter when the context change. MUSIC32 is an OSGi-based middleware for developing context-aware adaptive applications. It is a component-based and service-oriented approach, which principally consists of 2 different parts: the context and the adaptation middlewares. The adaptation middleware is responsible for adapting the applications, deploying the configuration that best fits the current context by evaluating a use function specified by the software architect. A difference between the MUSIC approach and our approach using DSPL is that they require the availability of all the valid configurations of the application at runtime, while our approach needs only the relationships (constraints) between the contexts and the valid configurations at runtime, while the configuration to deploy is generated on demand according the current context. Finally, Gamez et al propose a reconfiguration mechanism that switches among different configurations at runtime.33 The configurations are based on the specialisation of feature models, and the reconfiguration plans are automatically generated from the differences among them. They propagate changes in configurations at architectural level, but their approach does not support the reconfiguration of the component's parameters, as our approach does. 4IDEAL PARAMETER ESTIMATION The main objective of this paper is to provide an automated vehicle controller adaptive to contextual changes (eg, weather conditions) that adapts a vehicle's behaviour at runtime, without deteriorating traffic-flow safety and efficiency. Before presenting our reconfigurable vehicle controller, in this section, we estimate the optimised behavioural parameters that autonomous vehicles should use in different rainy conditions if they have full knowledge of the global traffic network.34 To do so, first, we need to assess the efficiency and safety theoretically achievable by autonomous vehicle control in mixed traffic under different environmental context. We perform offline global minimisation of a defined cost function, assuming full knowledge of the vehicles' speeds and headways in the network. The goal is to obtain the behavioural parameters (safe time headway and tolerated acceleration) of autonomous vehicles associated to each environmental context (in this paper, we focus on weather conditions: normal, light rain, and heavy rain) that maximises traffic quality in terms of efficiency and safety. F= N ∑ n=1 T ∑ t=0 safety ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ (vn−1(t)−vn(t) vmax )2 ·Psafety + efficiency ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ ⎛⎜⎜⎜⎜⎜⎜⎜⎜⎜⎝ Δxn(t)− Cte non-autonomous ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ 1 M M ∑ m=1 Δxm(t) Δxmax ⎞⎟⎟⎟⎟⎟⎟⎟⎟⎟⎠ 2 ·Pefficiency + comfort ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ (accn(t) accmax )2 ·Pcomfort (1) Concretely, we specify the cost function formulated in Equation 1 to be minimised, and which is inspired by Wang,35 since we also consider a safety, efficiency, and comfort cost. However, Wang's cost function35 is specific to the adaptive cruise control (ACC) algorithm for optimising the acceleration parameters, while our cost function (1) can be seen as more generic and can be used by any car-following model to optimise speed, acceleration, or time headway. The controller distinguishes “free driving mode” for the leading vehicles of the group of vehicles and “following mode” for all the other conventional and autonomous vehicles. The leader vehicle travels at the user-defined speed input v1. In following mode, vehicles try to maintain a desired †http://www.omg.org/spec/OCL/ TABLE 1 Optimal parameters obtained from the offline global minimisation of the cost function defined in (1) Parameters Normal conditions Light rain Heavy rain Acceleration: acc (m∕s2) 1.87 1.87 1.48 Time headway: Th (s)1.60 2.12 2.84 gap (efficiency cost) based on the variation of positions (Δx) while at the same time avoiding driving too close to the predecessor (safety cost). We also consider the driving comfort by including a comfort cost associated to the acceleration parameter to yield more comfortable accelerations and decelerations.35vmax,Δxmax,andaccmax are normalisation constants: vmax is the maximum speed of the current road (usually selected as the speed limit, here, 33 m/s) and thus is context based; Δxmax is the maximum desired space headway defined as Δxmax =vmax ·T+s0, where T=1.6seconds is the desired time gap and s0=2m is the gap in standstill conditions. Finally, accmax is the maximum acceleration11,35 that is chosen as 3 m/s2. We also assign weights to each term (Psafety,Pefficiency,andPcomfort) to adapt safety, efficiency, and comfort, respectively, to different contexts or drivers' preferences. The parameters values obtained with the offline global minimisation of the cost function (1), assuming full knowledge of the vehicles' speeds and headways under normal, and light and heavy rain conditions, are shown in Table 1. These values are close to the variations we expected, as defined in the previous section (section 2.2) for realistic behaviours. However, under realistic conditions, autonomous vehicles will only have a very local knowledge of other vehicles' variables,36 and the parameter valuesobtainedinthis sectionstillneedtobeestimatedaspreciselyaspossibleatruntime.Todothat,inthenextsection,weinvestigateadistributed modelpredictivecontrolleragentforautonomousvehicles to estimate their behaviouralparametersat runtime,basedontheiravailable knowledge of the system. We show that autonomous vehicles with the proposed reconfigurable controller agent lead to behaviour similar to that obtained theoretically offline, and thus to that achieved by human drivers, depending on the context. 5RECONFIGURABLE VEHICLE CONTROLLER AGENT This section describes our reconfigurable controller agent for the autonomous vehicles. First, we present the software architecture of the reconfigurable autonomous vehicle and model the knowledge needed to reconfigure its behaviour. Then, we present a model predictive controller agent to dynamically adapt the behavioural parameters of the vehicle. 5.1 Variability modelling of the autonomous vehicle: traffic context, vehicle behaviour, and traffic quality Figure 1 shows the variability model in CVL and the software architecture of the reconfigurable autonomous vehicle connected with the variability model. The variability model (top of Figure 1) specifies (1) the different contexts that can be detected by the sensors of the autonomous vehicle; (2) all the reconfigurable parameters of the autonomous vehicles that affect their behaviour, which includes the behavioural parameters (eg, speed, acceleration,andtimeheadway)andtheavailablecar-followingmodels andlane-changingprotocols;and(3) thetrafficqualityindicatorstotakeinto account. Each configurable feature is decomposed into choices in the tree, indicating which parameters are optional and which are mandatory. For instance, the BehaviouralParameters feature contains the configurable Speed,Acceleration,TimeHeadway,MaxSafeDeceleration, and JamDistance parameters; although in the example of this, paper we only consider Acceleration and TimeHeadway. The variability model also defines groups of features (as the CarFollowingModel feature) to specify the car-following model alternatives to be used. Dependencies between features are specified as cross-tree constraints in the OCL. We use OCL constraints to model the relationships between a specific context and the car-following model and lane-changing protocol of the autonomous vehicle to be used (see OCL constraints in Figure 1). For instance, the constraint RoadType.LocalStreet implies Vertigo means that when the autonomous vehicle drives through a local street, the lane-changing protocol will be reconfigured to use the Vertigo model, which is the appropriate model for that road type.4 ThebottomhalfofFigure 1showsthe completesoftwarearchitectureofthereconfigurable autonomousvehicle.Itspecifiesthesoftwarecomponentsthatimplementthefunctionality of eachmodule(sensors,contextchange detection,car-followingmodel,lane-changingprotocol, parameters of the vehicle itself, and traffic quality evaluation) and the relationships between the components. Therefore, in the DSPL, the variability model describesthepotentialrangeofvariationsthatcanbeproducedatruntimeforthe autonomousvehiclecontroller.Thedynamicvariationpoints,represented as dashed lines in Figure 1, link the features of the variability model and the components in the software architecture of the autonomous vehicle. The variation points model the possible adaptations that the software architecture supports. Specifically, each variation point (dashed line) defines a transformation (eg, object existence, object substitution, and parameter assignment) in the software architecture that will be executed by the CVL engine37 when a particular configuration is selected in the variability model, adapting the components of the autonomous vehicle.38,39 For example, when the context changes because the vehicle joins a motorway, a new configuration is generated: The new context is selected in the tree, FIGURE 1 Variability modelling of the autonomous vehicles: context, behaviour, and traffic quality. IDM, Intelligent Driver Model FIGURE 2 Reconfigurable vehicle controller agent and the IDM model is automatically selected in the configuration due to the cross-tree constraints defined in OCL. The CVL engine will resolve the variability, changing the IDM component to be the car-following model in the autonomous vehicle. However, although our DSPL handles this kind of dynamic reconfiguration of complete modules, this is beyond the scope of this paper, where we mainly focus on the optimisation of the behavioural parameters at runtime. Each configuration of the controller is a set of choices in the variability model (features in grey in Figure 1). In our approach, we first generate a particular configuration of the reconfigurable vehicle controller agent, which is able to detect changes in weather conditions (rain intensity) and evaluate the traffic quality based on the selected indicators of safety (time to collision, post-encroachment time) and efficiency (travel time). Then, during the simulation, the autonomous vehicle adapts its behaviour at runtime using a model predictive controller agent that optimises its behavioural parameters of the vehicle (ie, acceleration and time headway). 5.2 Model predictive controller agent Once we have generated an initial configuration of the autonomous vehicle controller, the behavioural parameters of the vehicle can be adapted at runtime to changes in the context. The model predictive controller agent component included in the architecture of the autonomous vehicles is in charge of adapting its behavioural parameters. Figure 2 details this component. 0 5 10 15 20 25 30 35 40 0 0.5 1 1.5 2 2.5 3 3.5 Autonomous vehicles number Acc Acceleration 0 5 10 15 20 25 30 35 40 0.5 1 1.5 2 2.5 3 3.5 4 Autonomous vehicles number Th Time Headway (A) Acceleration (Acc). (B) Time Headway (Th). FIGURE 3 Distributions of the parameters obtained at runtime for the autonomous vehicles Fn= St ∑ t=C+X safety ⏞⏞⏞⏞⏞⏞⏞ (vn(t) vmax )2 ·Psafety + efficiency ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ ⎛⎜⎜⎜⎜⎜⎜⎜⎜⎜⎜⎝ Δxn(t)− Cte non-autonomous ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ 1 M M ∑ m=1 C+X ∑ ta=C Δxm(ta) Δxmax ⎞⎟⎟⎟⎟⎟⎟⎟⎟⎟⎟⎠ 2 ·Pefficiency + comfort ⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞⏞ (accn(t) accmax )2 ·Pcomfort (2) The criteria to initiate a reconfiguration of the behavioural parameters is a contextual change. When a contextual change is detected (Context Change Detection) from the information gathered by the sensors, an optimisation algorithm is executed (Optimisation Algorithm in Figure 1). Autonomous vehicles have only a very local knowledge of other vehicles' variables (eg, positions and speeds). Consequently, we use an optimisation algorithm inspired from a distributed model predictive controller agent for autonomous vehicles to estimate their behavioural parameters at runtime,35 based on their available knowledge when the context changes. The objective function is defined in (2), similarly to the offline version defined in (1), but requires predicting the trajectory of the vehicle leader (v1). In this way, the optimisation algorithm starts the prediction Xseconds after the context changes (t=C) and simulates the trajectory of the leader with the current parameters during the simulation time (St). The prediction uses the information of the conventional vehicles for the safety term in (2) during the time interval (ta) defined from the context change (ta=C) until the optimisation algorithm starts (ta=C+X). The optimisation algorithm provides the suboptimal parameters values. Then, the global traffic quality of the vehicle network is evaluated (Traffic Quality Evaluation) using the selected indicators to be considered, and when the new predicted parameters for the autonomous vehicles improve the traffic quality, the values are adapted in the Vehicle Controller.The optimisation algorithm is then running continuously to improve the parameters in each iteration. Figure 3 represents the distributions of the acceleration and time headway parameters obtained at runtime with the online optimisation algorithm. We can observe how the acceleration values are decreased for each autonomous vehicle as expected when the weather conditions change from normal (1.83 m/s2on average) to light rain (1.82 m/s2) and to heavy rain (1.35 m/s2). The change in the acceleration parameter from normal conditions to light rain is almost imperceptible (a decrease by 0.59%), while the change from normal conditions or light rain to heavy rain is T ABLE 2 Ideal parameters vs optimised parameters of the model predictive controller agent Acceleration: acc (m/s2) Time headway:Th (s) Weather conditions Ideal Optimisation Ideal Optimisation Normal conditions 1.87 1.83 1.60 1.59 Light rain 1.87 1.82 2.12 2.05 Heavy rain 1.48 1.35 2.84 2.85 more relevant (a decrease by 26.40% from normal to heavy rain and a decrease of 25.96% from light rain to heavy rain conditions). Regarding the time headway parameter, the values notably increase as the weather conditions change. From normal conditions to light rain, the time headway is increased by 28.52% (from 1.59 to 2.05 s), while the change from normal to heavy rain conditions is substantial, with an increment in 78.95% (from 1.59 to 2.85 s in heavy rain conditions). The change from light rain to heavy rain supposes an increase by 39.23%. In all cases, the average values of the distributions converge to those obtained offline in Section 4, and as shown in the comparison in Table 2. 6EVALUATION To evaluate our reconfiguration approach, we compare our reconfigurable vehicle controller agent against autonomous vehicles without reconfiguration and evaluate the traffic quality of the vehicle network. Section 6.1 describes the 3 traffic quality indicators we use in our evaluation. The experimentation set-up is described in section 6.2 and the results in section 6.3. 6.1 Traffic quality indicators We use the following traffic quality indicators to evaluate safety and efficiency of the vehicle network. 6.1.1 Indicators of traffic safety • Time to collision (TTC): This is the estimated time at which a collision will occur if 2 vehicles keep the same trajectories and speeds40: TTC =Δxi−li Δvi =xi−xi−1−li vi−vi−1,(3) whereΔxiandΔviarethedifferenceofpositionandspeed,respectively,betweenthevehicleianditspredecessor,andliisthelengthofthevehicle i. A time to collision of 0 second means a direct collision. • Post-encroachment time (PET): This is the time difference between 2 vehicles passing a common spatial zone. It represents a direct collision risk,40,41 and a PET of 0 s is equivalent to a collision, so the objective is to maximise the post-encroachment time: PET =Δxi−li vi =xi−xi−1−li vi .(4) FIGURE 4 Simulating conventional vehicle behaviour