Maintaining driver attentiveness in shared-control autonomous driving
MMaintaining driver attentiveness in shared-controlautonomous driving
Radu Calinescu, Naif Alasmari and Mario Gleirscher
Department of Computer Science , University of York , York, U.K. { radu.calinescu,nnma500,mario.gleirscher } @york.ac.uk Abstract —We present a work-in-progress approach to improv-ing driver attentiveness in cars provided with automated drivingsystems. The approach is based on a control loop that monitors the driver’s biometrics (eye movement, heart rate, etc.) and thestate of the car; analyses the driver’s attentiveness level using adeep neural network; plans driver alerts and changes in the speedof the car using a formally verified controller; and executes thisplan using actuators ranging from acoustic and visual to hapticdevices. The paper presents (i) the self-adaptive system formedby this monitor-analyse-plan-execute (MAPE) control loop, thecar and the monitored driver, and (ii) the use of probabilisticmodel checking to synthesise the controller for the planning stepof the MAPE loop.
Index Terms —autonomous driving, shared control, MAPEcontrol loop, controller synthesis, probabilistic model checking
I. I
NTRODUCTION
The J3016 standard [1] classifies automated driving systems(ADSs) on a six-level scale, from no automation at Level 0to full automation at Level 5. Despite huge R&D budgets andmuch hype over the past decade, fully autonomous (Level 5)cars are unlikely to become available to the general public anytime soon. In contrast, cars providing Level 2 (i.e., partial)automation can be purchased from manufacturers includingTesla, Nissan and BMW; and the approval of Level 3 (i.e.,conditional automation) and 4 (i.e., high automation) cars isconsidered by regulators worldwide [2], [3], [4], [5], [6].A critical requirement for vehicles operating at autonomyLevels 2 and 3 is that a user resides in the driver’s seat and issufficiently attentive to be able to share the control of the carwith the ADS. At Level 2, this human in the loop is expected to‘ complete the object and event detection and response subtaskand [to] supervise the driving automation system ’, while atLevel 3 the user is expected to be ‘ receptive to ADS-issuedrequests to intervene [. . . ] and [to] respond appropriately ’ [1].Although Level 4 ADSs do not rely on human support, theymay still issue timely requests for human intervention (e.g.,when they approach roads or traffic situations they were notdesigned to handle), performing a minimum-risk manoeuvre(e.g., stopping the car safely) if their user does not respond.In all these scenarios, accidents with potentially fatal con-sequences (for Levels 2 and 3) and frequent emergency stops(for Level 4) can only be avoided if the drivers are sufficientlyattentive to be able to take over the control of their vehicles [7].However, humans find it extremely difficult to remain attentive
This research was funded by the Lloyds Register Foundation under theAssuring Autonomy International Programme grant Safe-SCAD. when overseeing the operation of automated and autonomoussystems [8], [9], [10]. In the automotive domain, this is amplydemonstrated by accidents involving both cars with Level 2ADS used by regular drivers [11], [12] and cars with higherautonomy levels tested by professional safety drivers [13].Our paper proposes an approach that mitigates this problemby using a monitor-analyse-plan-execute (MAPE) control loopto improve driver attentiveness in shared-control autonomousdriving. The monitoring component of this MAPE loop uses anarray of sensors to collect driver biometrics and vehicle data.The analysis component uses these data and a deep neuralnetwork [14] developed by a complementary research strandof our Safe-SCAD project to predict the driver response timeand response quality to a potential ADS intervention request.These predictions are processed based on a simple driverattentiveness model that factors in the speed of the car, and theresulting classification of the driver as attentive, semi-attentiveor inattentive guides the planning of driver alerts and carspeed changes by a formally verified discrete-event controller.This controller achieves Pareto-optimal trade-offs between risklevel, driver nuisance, and progress with the journey.The first version of our Safe-SCAD approach is aimed atLevel 3/4 ADSs, with a particular focus on the AutomatedLane Keeping System (ALKS) for which the United Na-tions World Forum for Harmonization of Vehicle Regulationsadopted a new UN regulation [6] in June 2020, and thatthe UK Department for Transport plans to implement onUK motorways [2]. For these advanced ADSs, the Safe-SCAD improvement in driver attentiveness can lead to fewerminimum-risk manoeuvres and better progress with the carjourney, and with minimal risk of accidents. Future enhance-ments (summarised later in the paper) will mitigate additionaluncertainties associated with the challenging problem tackledby our approach, extending its applicability to Level 2 ADSs,and to autonomous car testing by professional test drivers.The key contributions of the paper are the presentationof the driver attentiveness management problem in ALKS(as a motivating example, in Sect. II), the Safe-SCAD ap-proach to improving driver attentiveness in shared-controlautonomous driving (Sect. III), and the probabilistic modelchecking method for synthesising the Safe-SCAD planningcomponent (Sect. IV). The paper also discusses related work(Sect. V) and summarises our plans for future work (Sect. VI). Safety of Shared Control in Autonomous Driving, https://cutt.ly/Safe-SCAD a r X i v : . [ c s . R O ] F e b I. D
RIVER ATTENTIVENESS MANAGEMENT PROBLEM
A. Background
We consider an ADS with the characteristics stipulated inthe United Nations’ ALKS regulation [6]. The ALKS can beactivated by a driver (who must be available in the driving seat,with the seatbelt fastened) when all its components are fullyoperational, and the vehicle is on roads and in environment(e.g., weather) conditions within its operational design domain(ODD). When activated, the system keeps the vehicle insideits lane, controlling the vehicle speed (within the range 0 to60 km/h) to adapt to the surrounding road traffic. Additionally,the ALKS can detect the risk of collision (e.g., due to astationary vehicle) and can stop to avoid the collision, e.g.,by performing an emergency manoeuvre.In certain situations, all of which it must recognise, theALKS issues a transition demand , i.e., a request for the driverto take over the control of the vehicle. The regulation allowsthese situations to differ across manufacturers. However, theymust include the situations in which the ALKS activationconditions are not met (e.g., the vehicle approaches a roadoutside its ODD), and those in which the driver is unavailable(i.e., not in the driving seat or inattentive ) and not respondingto ALKS alerts aimed at restoring the driver’s availability.Transition demands are issued timely, allowing (i) an attentivedriver to resume the manual driving safely, or (ii) the ALKS toperform a minimum-risk manoeuvre (MRM), e.g., to bring thevehicle to a standstill, if the driver is inattentive. The ALKSmay reduce the vehicle speed to ensure safety, e.g., by allowingthe driver additional time for the control takeover.It follows from the summary so far that the ALKS mustbe capable of assessing the driver’s availability, includingtheir position in the car (in the driving seat, wearing theseatbelt) and their attentiveness. For the latter, the regulationproposes the use of driver biometrics such as ‘eye blinking,eye closure, conscious head or body movement’ [6], butallows manufacturers to select their own methods for assessingdriver attentiveness. Likewise, the regulation and UK’s ALKSplan [2] recommend the use of optical, acoustic and hapticwarning signals (i) to announce transition demands to thedriver, and (ii) to improve driver attentiveness, but are notprescriptive about how these alerts should be used. In the nextsection, we use these recommendations to define the driverattentiveness management problem for ALKS-like ADsS.
B. Problem definition
Given an ALKS, we assume that its driver can have oneof n ≥ attentiveness levels. The highest level (‘attentive’)corresponds to the situation in which the driver can respondtimely to a transition demand, even at the maximum speedpermitted for the vehicle. The lowest level (‘inattentive’)corresponds to the situation where the ALKS needs to executean MRM unless the driver improves their level of attentivenesswithin a mandated time period τ > . If present, any inter-mediate levels (e.g., ‘semi-attentive’ for n = 3 ) correspond to The UK consultation document proposes τ = 15 s [2, p. 17]. diminished driver attentiveness that does not require an MRM.However, they provide an opportunity for issuing alerts toimprove the driver’s attentiveness level before it drops further,and drastic action is required: MRMs involve stopping thevehicle in a motorway lane [2], [6], and should only be usedas a last resort.We assume that the ADS has two mechanisms it can usewhen the driver is not ‘attentive’. First, it can activate one orseveral of m ≥ alerts (e.g., optical, acoustic and haptic) asneeded to improve the driver’s attentiveness. Second, it canreduce the car speed to one of q ≥ speed levels, where weallow q = 1 for the case when this feature is not available. Assuch, the ALKS state at any point in time is characterised by:1) the driver attentiveness level l ∈ { , , . . . , n − } , where l = 0 and l = n − correspond to the driver being‘attentive’ and ‘inattentive’, respectively;2) the set of active alerts a ∈ { , } m , where a =( a , a , . . . , a m ) indicates that the i -th alert is inactivewhen a i = 0 , and active when a i = 1 ;3) the vehicle speed level v ∈ { , , . . . , q − } .Using the notation L = { , , . . . , n − } , A = { , } m and V = { , , . . . , q − } to denote the range for the threecomponents of the ALKS state, we further assume that thefollowing measures are defined over the state space L × A × V :1) nuisance : A → R ≥ , where nuisance ( a ) representsthe nuisance experienced by the driver when the alerts a ∈ A are in use, with nuisance (0 , , . . . ,
0) = 0 ;2) progress : V → R ≥ , where progress ( v ) reflects theprogress with the journey made when the vehicle travelsat speed v ∈ V (e.g., the distance travelled in one hour);3) risk : L × V → R ≥ , where risk ( l, v ) provides ameasure of the risk associated with travelling at speed v ∈ V when the driver attentiveness level is l ∈ L ,and that risk MRM > denotes the risk associated withperforming an MRM.Finally, we assume that timing data are available about thedrivers’ transition between the attentiveness levels L , whendifferent alert combinations are active, and at different vehiclespeeds. These data may be available from studies of driverbehaviour [15], [16], experiments carried out by ALKS man-ufacturers, observations of drivers who are using the deployedADS, or a combination thereof. Given such data, the driverattentiveness management problem is to find a combination ofalerts a ( s ) ∈ A to use in each ALKS state s ∈ L × A × V , suchthat the ALKS achieves Pareto optimality between minimisingthe driver nuisance, maximising the progress with the journey,and minimising the risk over a period of T hours of driving.III. T HE S AFE -SCAD
APPROACH
Our Safe-SCAD approach addresses the driver attentivenessmanagement problem from Section II-B by using a MAPEcontrol loop with the components shown in Figure 1. Thesecomponents and the four stages of the MAPE loop aredescribed in the following sections. We provide only a briefsummary for the components used in the first two MAPE2 ensor data alerts/speed planPlan executionmoduleMonitor driverattentionlevelDNN-basedanalysis module Discrete-eventcontrollerdriversensors carsensors alerteffectors speedeffectors
Fig. 1. Safe-SCAD driver attentiveness management approach for ALKS with n = 3 attentiveness levels (attentive, semi-attentive, and inattentive) stages (monitoring and analysis), as their technical details areavailable in [14], [17], and we focus instead on their integrationinto a MAPE loop and on the planning MAPE stage, whichrepresent the two key theoretical contributions of this paper. A. Monitoring
In this MAPE stage, data are collected from a combina-tion of driver-biometrics sensors and vehicle sensors. In ourproject, driver biometrics are obtained [14] using: (i) eye-tracking glasses to monitor eye movement data (e.g., gazeposition and fixation time); (ii) smartwatch photoplethysmo-graphic sensors to monitor heart rate; and (iii) smartwatchgalvanic skin response sensors to monitor hand sweating. Abroad range of vehicle data streams are already collected andused by ADSs, and can easily be exploited within our MAPEloop. These range from vehicle velocity and steering wheelangle to lane position and throttle/brake pedal angles.
B. Analysis
This MAPE stage (Figure 2) uses the DeepTake predictorof driver takeover behaviour [14] developed by another Safe-SCAD research strand. DeepTake is a deep neural network(DNN) that uses the driver-biometrics and vehicle data fromthe monitoring stage to predict the driver’s control takeover:1) intention , i.e., whether the driver would react to an ADScontrol-transition demand or not;2) time elapsed from the transition demand until the driverassumes manual control of the vehicle, as defined by theISO 21959 standard [18];3) quality of the driver’s manoeuvring of the vehicle aftermanual control is resumed.DeepTake was shown [14] to predict these driver takeovermetrics with an accuracy of 96%, 93% and 83%, respectively.We emphasise that these accuracy levels are sufficient forthe Safe-SCAD driver attentiveness management because oursolution is intended for use with ALKS that can ensure safetyat all times, e.g., by performing an MRM if necessary. takeover intentiontakeover timetakeover qualitysensor data driverattentionlevelDeepTake DNNverificationresultsDeepTake deepneural network Attention levelcalculatorDNN-based analysis module
Fig. 2. Safe-SCAD analysis MAPE stage
Additionally, our DNN-based analysis module operates con-servatively by also exploiting the results from the design-time robustness verification of DeepTake [17]. Figure 3 showshow we intend to use these verification results in the post-processing of the DeepTake predictions, such that the com-puted driver attention level is lowered when the sensor databelongs to regions of the DeepTake input space that were notidentified as robust by the DNN verification. This part of ourSafe-SCAD approach is under development.
C. Planning
In this MAPE stage, a discrete-event controller plans theset of active alerts a ∈ A and the speed level v ∈ V thatthe vehicle should employ. This controller is activated by theoccurrence of two types of events: • changes in the attentiveness level of the driver; • the expiry of a timer that is used to activate the controllerperiodically at all times when the driver attentivenesslevel is not ‘attentive’.The timer enables the controller to periodically “try” new oradditional alerts and/or speed adjustments when the driver at-tentiveness level was not improved by the execution of the plandevised by the previous controller activation. The synthesis ofthe Safe-SCAD controller is detailed in Section IV. speedtakeover time speedtakeover time t a k e o v e r qu a li t y verified robustness of DNN-input region that sensor data belongs toAA IIS S speedtakeover timeA IS speedtakeover timeA ISlow high l o w h i g h Fig. 3. The driver attention level (A=attentive, S=semi-attentive, I=inattentive)depends on the predicted driver takeover time and quality, on the speed of thevehicle, and on the verified robustness of the DeepTake input region that thesensor data belongs to. The diagram applies to a positive takeover intention(i.e., driver responsive to a control-transition demand); when DeepTakepredicts a negative intention, the driver state is deemed inattentive. . Execution In this MAPE stage, the alert and speed effectors of thevehicle are used to implement the alerts and speed planprovided by the Safe-SCAD controller.IV. S
AFE -SCAD
CONTROLLER SYNTHESIS
To synthesise the Safe-SCAD controller used in the plan-ning MAPE stage, we model the relevant behaviour of theself-adaptive system from Figure 1 as a parametric continuous-time Markov chain (CTMC). The parameters of this CTMCare chosen such that the (non-parametric) CTMC inducedby each combination of parameter values corresponds to adifferent feasible controller, and the CTMCs obtained byconsidering all valid combinations of parameter values definethe set of feasible Safe-SCAD controllers, i.e., the controllerdesign space . Given this design space, we synthesise formallyverified controllers by using (i) probabilistic model checkingto determine the nuisance , progress and risk associated withany specific controller; and (ii) multi-objective genetic algo-rithms to find controllers that achieve Pareto-optimal trade-offs between these three measures. We detail the steps of ourcontroller synthesis process in Sections IV-B and IV-C, after abrief introduction to continuous-time Markov chains and theirprobabilistic model checking in Section IV-A. A. Continuous-time Markov chains
A CTMC is a finite state-transition model M = ( S, s , R ) ,where S is a finite set of states, s ∈ S is the initial state,and R : S × S → [0 , ∞ ) is a transition rate matrix suchthat for any state s i ∈ S , the probability that the CTMC willtransition from state s i to another state within t > time unitsis − e − t · (cid:80) sk ∈ S R ( s i ,s k ) , and the probability that the new stateis s j ∈ S is given by R ( s i , s j ) / (cid:80) s k ∈ S R ( s i , s k ) .To enable the analysis of a broader range of CTMC proper-ties, the states and transitions of a CTMC are often annotatedwith rewards . A reward structure over a CTMC with state set S is a pair of functions r X = ( r , r ) , where r : S → R ≥ isa state reward function that defines the rate r ( s ) at which thereward is obtained while the Markov chain is in state s ; and r : S × S → R ≥ is a transition reward function that definesthe reward obtained each time a transition occurs.Probabilistic model checkers such as PRISM [19] andStorm [20] use efficient symbolic model checking techniquesto analyse a wide range of CTMC properties expressed in con-tinuous stochastic logic (CSL) augmented with rewards [21].These properties include bounded and unbounded probabilisticreachability, and several types of reward properties. For ourSafe-SCAD controller synthesis, we are interested in cumula-tive reward properties . These properties are expressed usingthe CSL formula R X =? [ C ≤ T ] , which denotes the expected valueof the reward X accrued within the time interval [0 , T ] . B. Safe-SCAD controller design space
We model the driver attentiveness management problemusing a family of CTMCs to define the design space (i.e., thepossible variants) of the Safe-SCAD controller. Each CTMCin the family has the state set S = L × A × V ×{ c, c } , where L , A and V are defined in Section II-B, and c is a Boolean statevariable that indicates whether the discrete-event controlleris active or not. As shown in Figure 4, which depicts thecontroller design space for a specific instance of the problem,the model has three types of state transitions:1) Transitions corresponding to changes in driver attentiveness.
These transitions occur from states ( l, a, v, c ) , in which thecontroller is inactive, to states ( l (cid:48) , a, v, c ) with a differentdriver attentiveness level (i.e., l (cid:48) (cid:54) = l ), no changes in thealerts a and speed v , and the controller activated.2) Transitions corresponding to fixed controller actions.
Thereare two classes of such actions. In the first, the CTMCtransitions from states ( (cid:48) A (cid:48) , a, v, c ) , in which the driver isattentive and the controller activated, to the initial state ( (cid:48) A (cid:48) , (0 , , , c ) ; this happens whenever the controller isactivated by a change in driver attentiveness level, findsthe driver fully attentive, and therefore switches off anyactivated alerts, and selects the nominal driving speed. Inthe second, the controller is activated by a timer wheneverthe driver has not become fully attentive after a period oftime since a previous controller action. In this situation, the a v =000 a v =001 a v =111 A, c S, c I, c A, c S, c I, c S, c I, c A, c S, c I, c S, c I, c A, c S, c I, c fixed controller transitioncontroller transition optionCTMC state correspondingto driver attentiveness level l = (cid:48) I (cid:48) , alerts a = (0 , ,speed level v = 1 , andcontroller activateddriver-attentiveness changetransition I, c a v =001 Fig. 4. Safe-SCAD controller design space for the driver attentiveness management problem with three driver attentiveness levels ( L = { (cid:48) A (cid:48) , (cid:48) S (cid:48) , (cid:48) I (cid:48) } , where A =attentive, S =semi-attentive and I =inattentive), two alerts ( A = { , } ) and two speed levels ( V = { , } ). In the initial state (indicated by an incomingarrow) the driver is attentive, the controller is inactive, the alerts a = (0 , are inactive, and the car drives at nominal speed level v = 0 ; for brevity, thiscombination of alert activations and speed level is denoted a v = 000 in the diagram. ( l, a, v, c ) with l (cid:54) = (cid:48) A (cid:48) to the counterpart state ( l, a, v, c ) in which the activatedcontroller has the opportunity to switch on new alerts and/orto select a new speed level.3) Transitions corresponding to controller options.
When thecontroller is activated (by a change in driver attentivenesslevel or by the timer) and finds the driver to not be fullyattentive, it has a choice of using any available combina-tion of alerts and any speed level in order to make thedriver attentive and to reduce risk. Thus, from each state ( l, a, v, c ) ∈ S with l (cid:54) = (cid:48) A (cid:48) , the CTMC can transition to anystate ( l, a (cid:48) , v (cid:48) , c ) ∈ S . These controller options are indicatedby dashed transitions in Figure 4. In the general case fromSection II-B, there are n driver attentiveness levels, m alertsand q speed levels, giving the controller m q combinationsof alerts and speed level options to choose from in eachof the ( n − m q CTMC states in which l (cid:54) = (cid:48) A (cid:48) . Weencode the controller option for each of the n − driverattentiveness levels l ∈ L \ { (cid:48) A (cid:48) } and each of the m q combinations of alerts and speed level a v ∈ A × V usinga design-space parameter option l,a v ∈ { , , . . . , m q − } . (1)We have ( n − m q such parameters, and each assign-ment of values to these parameters defines a candidatedeterministic controller solution for the driver attentivenessmanagement problem. There are (2 m q ) ( n − m q candidatesolutions in total, and thus (2 (3 − = 8 ≈ candidate solutions for the problem instance encoded bythe parametric CTMC from Figure 4.To complete the definition of the controller design space, wealso need to specify its CTMC transition rates. The last twotypes of transitions described above correspond to controlleractions. Therefore, their rates must reflect the mean operationtime that the controller requires: (i) to plan the new alerts andspeed level when it is activated, and (ii) to be activated byits timer. For instance, a controller operation time of 500msgives a rate of 2s − . These rates are easy to determine, e.g., byworst-case execution time analysis of the controller code. Incontrast, the rates for the first type of transition are much moredifficult to determine because they encode the mean time takenby the driver to transition between attentiveness levels, for eachcombination of active alerts and speed levels. These rates mustbe estimated, e.g., by using data sources such as:1) the numerous available studies and surveys of driver atten-tiveness, e.g. [22], [15], [16], [23];2) additional data from controlled experiments with drivers ofALKS vehicles;3) driver data collected during the actual driving of ALKSvehicles, e.g., by using a black-box solution similar to thatalready employed by many insurers of new drivers [24],[25], either across a fleet of vehicles or for a specific driver. A deterministic controller is a controller which, for any state s ∈ S ,performs the same action each time when state s is reached. We note that using the last data source enables both (i) thedefinition of personalised controller design spaces for eachdriver, and (ii) the continual updating of these design spacesto support the runtime synthesis of new Safe-SCAD controllerswhen the transition rates for a driver change significantly [26].
C. Synthesis of Pareto-optimal Safe-SCAD controllers
The synthesis of Safe-SCAD controllers solves the driverattentiveness management problem. For this purpose, wedefine the reward structures r nuisance , r progress and r risk over the CTMCs from our controller design space. Thedefinitions of these reward structures are directly based onthe definitions of the three measures with the same namesfrom Section II-B. For instance, the state and transitionreward functions for the first reward structure are given by r nuisance .r ( l, a, v, c ?) = nuisance ( a ) for any CTMC state ( l, a, v, c ?) ∈ S , and r nuisance .r ( s , s ) = 0 for any CTMCtransition ( s , s ) ∈ S × S , respectively. Given these rewardstructures, the driver attentiveness management problem for ajourney of duration T > can be formalised as: Find the set of controller options (1) whose associatedCTMCs from the controller design space achieve Pareto-optimal trade-offs between minimising R nuisance =? [ C ≤ T ] ,maximising R progress =? [ C ≤ T ] and minimising R risk =? [ C ≤ T ] , where the three CSL cumulative reward properties representthe overall nuisance, overall progress with the journey, andoverall risk accrued over a journey of duration T , respectively.We solve this problem using the search-based softwareengineering tool EvoChecker [27], [28], which:1) obtains the precise values of the three reward properties forany given CTMC from the controller design space using aprobabilistic model checker (the tool can be configured touse PRISM [19] or Storm [20]);2) synthesises a close approximation of the Pareto-optimal setof controller options (1) by using multi-objective geneticalgorithm (MOGA) optimisation (the tool can be configuredto work with any of the NGSA-II [29], SPEA2 [30] orMOCell [31] MOGAs).To this end, we supply EvoChecker with: (i) our controllerdesign space from Section IV-B, encoded in the high-levelPRISM modelling language [19] extended with EvoCheckerconstructs that we use to specify the possible values forthe parameters (1); and (ii) the three CSL reward propertiesspecifying the optimisation objectives from our problem. Fig-ure 5 shows how the controller design space from Figure 4is expressed in this encoding. Due to space constraints, onlya fragment of the encoding is shown, but we made the entireencoding (and the other artifacts from this section) availablefor inspection at https://cutt.ly/SafeSCAD-SEAMS21. Giventhe controller design space and the optimisation objectives,EvoChecker synthesises a close approximation of the Pareto-optimal set of Safe-SCAD controllers, and the Pareto frontassociated with this set. Figure 6 shows the Pareto front ob-tained for the instance of the driver attentiveness management5 / Controller options specifying the next a v ∈ { (2) , (2) , . . . , (2) } value evolve int option S , [0..7]; // when driver is semi-attentive and a v = 000 (2) . . . evolve int option S , [0..7]; // when driver is semi-attentive and a v = 111 (2) evolve int option I , [0..7]; // when driver is inattentive and a v = 000 (2) . . . evolve int option I , [0..7]; // when driver is inattentive and a v = 111 (2) module Controller c : [0..1] init
0; // 0 = controller inactive, 1 = controller active a v : [0..7] init
0; // current alerts a and speed level v // activate controller[driver change] c =0 → ( c (cid:48) = 1 ); // when driver state changes[ ] c = 0 ∧ l (cid:54) = 0 → timerRate : ( c (cid:48) = 1) ; // periodically if driver not attentive// switch off alerts and use nominal speed if the driver is attentive ( l = 0 )[ ] c = 1 ∧ l = 0 → controllerRate : ( a v (cid:48) = 0)&( c (cid:48) = 0) ;// controller actions for driver attentiveness level l = 1 (semi-attentive)[ ] c = 1 ∧ l = 1 ∧ a v = 0 → controllerRate : ( a v (cid:48) = option S , )&( c (cid:48) = 0) ;. . .[ ] c = 1 ∧ l = 1 ∧ a v = 7 → controllerRate : ( a v (cid:48) = option S , )&( c (cid:48) = 0) ;// controller actions for driver attentiveness level l = 2 (inattentive)[ ] c = 1 ∧ l = 2 ∧ a v = 0 → controllerRate : ( a v (cid:48) = option I , )&( c (cid:48) = 0) ;. . .[ ] c = 1 ∧ l = 2 ∧ a v = 7 → controllerRate : ( a v (cid:48) = option I , )&( c (cid:48) = 0) ; endmodule Fig. 5. Fragment of EvoChecker-encoded controller design space for m = 2 independent alerts and q = 2 speed levels with the design space from Figure 4 and a driving time of T = 4 hours. Each element of this Pareto front corresponds toa controller variant whose nuisance, risk and progress valuesfrom Figure 6 were obtained by EvoChecker through formalverification using the Storm model checker.V. R ELATED WORK
Human-machine interaction in driving automation includesthe identification and handling of control transitions betweenthe driver and the vehicle [32], [18] and, in support of that,managing the driver’s attentiveness and involvement necessaryfor such transitions, taking into account the current trafficsituation with its potential adversity.Recent research deals with managing such control transi-tions [18], [33] or continuous shared control [32], and includesinventions about control transitions that require but do notmanage driver attentiveness [33], [34], [35]. Similarly, anearlier invention [36] focuses on classifying the driver stateand on technologies for situation-adapted collision avoidanceby combining braking and driver warnings. A range of experi-ments [37], [38], [39] investigate parameters of the driver stateand behaviour (e.g. response times, drowsiness, influence oftraffic density and driver workload), however, with little dataabout the time it takes drivers to become inattentive.Overall, none of the works we found discusses how atten-tiveness monitoring and control software can be automaticallydesigned and adapted for optimal safety and performance,and how such software can be confidently assured to fulfilregulatory requirements [40]. In contrast, our Safe-SCAD ap-proach focuses on the design and analysis of a MAPE controlloop supported by such software, assuming the availability ofspecific sensor technology for estimating the driver state [37].Moreover, we provide a generic method for defining the designspace for this control software, and for its automated synthesiswith probabilistic guarantees. Finally, our exhaustive formal
Fig. 6. Pareto front associated with the set of Pareto-optimal Safe-SCAD con-trollers for the controller design space instance from Figure 4, as synthesisedin 98.58s by EvoChecker configured to use Storm [20] and NSGA-II [29](population size 7000 × verification approach based on probabilistic model checking isalso an improvement over the purely testing-based approachthat the safety of the intended functionality (SOTIF) standardrecommends for the verification of automated driving systems[40, §10.3, Table 5-7].VI. C ONCLUSION
We introduced a MAPE control loop for improving driverattentiveness in ADS-enhanced cars, and we described a novelmethod for the rigorous synthesis of the controller used inthe planning stage of this MAPE loop. In the next stageof our project, we will complete the development of theDNN-based analysis module from Figure 2 by integrating ourproject’s DeepTake predictor of driver takeover behaviour [14]and its verification results [17] into the end-to-end solutionpresented in this paper. The complete solution will then beevaluated experimentally, in a study carried out using ourdriving simulator from [14].Additionally, we will assess whether the good EvoCheckerscalability reported in [28] extends to our controller synthesisproblem with larger numbers of alerts m and speed levels q (cf. Section II-B). Finally, we plan to explore: (i) theuse of personalised and adaptive controllers (as described inSection IV-B); (ii) the use of the CTMC-refinement techniquefrom [41], [42] to improve the accuracy of the Safe-SCADcontroller design space; (iii) the use of the robust synthesistechniques from [43], [44] to generate controllers tolerant tovariations in driver behaviour; and (iv) the potential advantagesof using probabilistic Safe-SCAD controllers, i.e., controllersfor which the options (1) are discrete probability distributionsover the set of actions available to the controller.A CKNOWLEDGEMENTS
This project has received funding from the Assuring Auton-omy International Programme project ‘Safety of shared controlin autonomous driving’ and the UKRI project EP/V026747/1‘Trustworthy Autonomous Systems Node in Resilience’.6
Official Journal of the European Union , vol. L 325/1, 2019.[5] T. Imai, “Legal regulation of autonomous driving technology: Currentconditions and issues in Japan,”
IATSS Research , vol. 43, no. 4, pp.263–267, 2019.[6] UNECE World Forum for Harmonization of Vehicle Regulations,“ECE/TRANS/WP.29/2020/81: United Nations Regulation on Uniformprovisions concerning the approval of vehicles with regard toAutomated Lane Keeping Systems,” June 2020. [Online]. Available:https://cutt.ly/ALKS-regulation[7] N. Merat and A. H. Jamson, “How do drivers behave in a highlyautomated car?” in . University of Iowa, 2009.[8] R. Chai, G. R. Naik, T. N. Nguyen et al. , “Driver fatigue classificationwith independent component by entropy rate bound minimization anal-ysis in an eeg-based system,”
IEEE Journal of Biomedical and HealthInformatics , vol. 21, no. 3, pp. 715–724, 2016.[9] J. F. Duffy, K.-M. Zitting, and C. A. Czeisler, “The case for addressingoperator fatigue,”
Reviews of Human Factors and Ergonomics , vol. 10,no. 1, pp. 29–78, 2015.[10] G. Matthews and P. A. Hancock,
The Handbook of Operator Fatigue .CRC Press, 2017.[11] V. A. Banks, K. L. Plant, and N. A. Stanton, “Driver error or designererror: Using the perceptual cycle model to explore the circumstancessurrounding the fatal Tesla crash on 7th May 2016,”
Safety Science
PLoS one , vol. 12, no. 9, p. e0184952, 2017.[14] E. Pakdamanian, S. Sheng, S. Baee, S. Heo, S. Kraus, and L. Feng,“DeepTake: Prediction of driver takeover behavior using multimodaldata,” in
ACM CHI Conference on Human Factors in ComputingSystems , 2021. [Online]. Available: https://arxiv.org/abs/2012.15441[15] A. Lotz and S. Weissenberger, “Predicting take-over times of truckdrivers in conditional autonomous driving,” in
International Conferenceon Applied Human Factors and Ergonomics , 2018, pp. 329–338.[16] Q. Maia, M. A. Grandner et al. , “Short and long sleep duration andrisk of drowsy driving and the role of subjective sleep insufficiency,”
Accident Analysis & Prevention , vol. 59, pp. 618–622, 2013.[17] J. M. Grese, C. Pasareanu, and E. Pakdamanian, “Formal analysisof a neural network predictor in shared-control autonomous driving,”in
AIAA Scitech 2021 Forum
CAV’11 , 2011, pp. 585–591.[20] C. Dehnert, S. Junges, J.-P. Katoen, and M. Volk, “A Storm is coming:A modern probabilistic model checker,” in
CAV’17 , 2017, pp. 592–600.[21] M. Kwiatkowska, G. Norman, and D. Parker, “Stochastic model check-ing,” in
Formal Methods for the Design of Computer, Communicationand Software Systems: Performance Evaluation . Springer, 2007, pp.220–270. [22] M. K¨orber, L. Prasch, and K. Bengler, “Why do I have to drive now?Post hoc explanations of takeover requests,”
Human Factors , vol. 60,no. 3, pp. 305–323, 2018.[23] W. Vanlaar, H. Simpson, D. Mayhew, and R. Robertson, “Fatigued anddrowsy driving: A survey of attitudes, opinions and behaviors,”
Journalof safety research , vol. 39, no. 3, pp. 303–309, 2008.[24] A. Kassem, R. Jabr, G. Salamouni, and Z. K. Maalouf, “Vehicle blackbox system,” in , 2008, pp. 1–6.[25] M. A. Kumar, M. V. Suman, Y. Misra, and M. G. Pratyusha, “Intelligentvehicle black box using IoT,”
Int. J. Eng. Technol , vol. 7, no. 2, pp. 215–218, 2018.[26] X. Zhao, R. Calinescu, S. Gerasimou, V. Robu, and D. Flynn, “Inter-val change-point detection for runtime probabilistic model checking,”in . IEEE, 2020, pp. 163–174.[27] S. Gerasimou, G. Tamburrelli, and R. Calinescu, “Search-based synthe-sis of probabilistic models for quality-of-service software engineering(t),” in . IEEE, 2015, pp. 319–330.[28] S. Gerasimou, R. Calinescu, and G. Tamburrelli, “Synthesis of proba-bilistic models for quality-of-service software engineering,”
AutomatedSoftware Engineering , vol. 25, no. 4, pp. 785–831, 2018.[29] K. Deb, A. Pratap, S. Agarwal, and T. Meyarivan, “A fast and elitistmultiobjective genetic algorithm: NSGA-II,”
IEEE Transactions onEvolutionary Computation , vol. 6, no. 2, pp. 182–197, 2002.[30] E. Zitzler, M. Laumanns, and L. Thiele, “SPEA2: Improving the strengthpareto evolutionary algorithm,”
TIK-report , vol. 103, 2001.[31] A. J. Nebro, J. J. Durillo, F. Luna et al. , “MOCell: A cellular geneticalgorithm for multiobjective optimization,”
International Journal ofIntelligent Systems , vol. 24, no. 7, pp. 726–746, 2009.[32] M. Walch, K. M¨uhl, J. Kraus, T. Stoll, M. Baumann, and M. Weber,“From car-driver-handovers to cooperative interfaces: Visions for driver-vehicle interaction in automated driving,” in
Automotive User Interfaces .Springer, 2017, pp. 273–294.[33] R. Latotzki and F. Goseberg, “Handover procedure for driver of con-trolled vehicle,” Germany Patent US 2020/0 103 898 A1, 2020. [Online].Available: https://patents.google.com/patent/US20200103898A1/en[34] P. L. G. Martinez and J. Yu, “Collision mitigation systems and methodsusing driver attentiveness,” Worldwide Patent US9 047 780B2, 2013.[Online]. Available: https://patents.google.com/patent/US9047780B2/en[35] B. Hoye, “Determining driver engagement with autonomous vehicle,”U.S. Patent US10 209 708B2, 2016. [Online]. Available: https://patents.google.com/patent/US10209708B2/en[36] M. Kopf and N. Farid, “Systems and methods for evaluating driver atten-tiveness for collision avoidance,” Germany Patent US7 592 920B2, 2004.[Online]. Available: https://patents.google.com/patent/US7592920B2/en[37] C. Gold, D. Damb¨ock, K. Bengler, and L. Lorenz, “Partially automateddriving as a fall-back level of high automation,” in
6. TagungFahrerassistenzsysteme: Der Weg zum automatischen Fahren , vol. 28,2013. [Online]. Available: https://mediatum.ub.tum.de/doc/1187198/[38] F. Biondi, D. L. Strayer, R. Rossi et al. , “Advanced driver assistancesystems: Using multimodal redundant warnings to enhance road safety,”
Applied Ergonomics , vol. 58, pp. 238–244, 2017.[39] T. E. Trimble, R. Bishop et al.
IEEEInternational Conference on Software Architecture , 2017, pp. 121–130.[42] ——, “Observation-enhanced QoS analysis of component-based sys-tems,”
IEEE Trans. Softw. Eng. , vol. 46, no. 5, pp. 526–548, 2018.[43] R. Calinescu, M. ˇCeˇska, S. Gerasimou, M. Kwiatkowska, and N. Pao-letti, “Efficient synthesis of robust models for stochastic systems,”
Journal of Systems and Software , vol. 143, pp. 140–158, 2018.[44] R. Calinescu, M. ˇCeˇska, S. Gerasimou, M. Kwiatkowska, and N. Pao-letti, “Designing robust software systems through parametric Markovchain synthesis,” in
IEEE International Conference on Software Archi-tecture , 2017, pp. 131–140., 2017, pp. 131–140.