Temporal Logic Formalisation of ISO 34502 Critical Scenarios: Modular Construction with the RSS Safety Distance

As the development of autonomous vehicles progresses, efficient safety assurance methods become increasingly necessary. Safety assurance methods such as monitoring and scenario-based testing call for formalisation of driving scenarios. In this paper, we develop a temporal-logic formalisation of an important class of critical scenarios in the ISO standard 34502. We use signal temporal logic (STL) as a logical formalism. Our formalisation has two main features: 1) modular composition of logical formulas for systematic and comprehensive formalisation (following the compositional methodology of ISO 34502); 2) use of the RSS distance for defining danger. We find our formalisation comes with few parameters to tune thanks to the RSS distance. We experimentally evaluated our formalisation; using its results, we discuss the validity of our formalisation and its stability with respect to the choice of some parameter values.


INTRODUCTION
To increase social acceptance of automated driving vehicles (ADVs), addressing safety concerns is vital.The safety vision of the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29) states that the level of safety should be such that ADVs "shall not cause any traffic accidents resulting in injury or death that are reasonably foreseeable and preventable" [8].
One path towards realising this vision is scenario-based testing of vehicle controllers [21].For this approach, a library of critical scenarios is compiled, and the behaviour of the path-planning algorithm in these situations is observed through simulations.Compared to a posteriori analysis of recorded driving data, this allows for cost-efficient testing and adjustments of controllers, as it is not necessary to record new driving data after algorithmic changes.
Efforts towards standardising test-scenario based ADV safety evaluations include ISO Standard 34502 [12].This standard derives relevant scenarios by systematically identifying risk factors related to vehicle perception, traffic conditions, and vehicle control.Combining these factors yields a large number of critical scenarios.
Most efforts towards specifying critical scenarios use a combination of natural language descriptions and suitably chosen parameter value ranges, see e.g.[20].An alternative is formalisation of critical scenarios, in some formal language with a rigorously defined semantics, so that 1) the content of each scenario is mathematically well-defined, and 2) those scenarios can be mechanically processed by software.A typical example of such processing is monitoring, i.e. detecting occurrences of scenarios automatically in a driving log.
A class of formal languages particularly suitable for this purpose is temporal logics, pioneered by Pnueli [23].Temporal logics can be thought of as extensions of propositional logics with so-called temporal operators, allowing for statements that refer to temporal relationships such as always or eventually in the future.Well-known examples of temporal logics are LTL, CTL and CTL ★ ; they all have discrete notions of time.For the purpose of formalising critical scenarios, their extensions to continuous time are suited, such as metric temporal logic (MTL) [14] and signal temporal logic (STL) [19].
In this paper, we provide a logical formalisation in STL of an important class of critical scenarios in ISO 34502, namely traffic disturbance scenarios for general vehicles on highways.Our formalisation has two unique characteristics.The first one is its modularity: a common template of the formulas for different scenarios is first fixed, and then the component formulas in the template are instantiated.This construction-it mirrors the top-down compositional methodology in ISO 34502-aids systematic, comprehensive formalisation.The second characteristic is the use of the RSS distance [28], a distance considered safe between two moving vehicles, for defining danger.We find that this makes our formalisation more stable by reducing the number of parameters to be tuned.We also report our use of our tool called STL Debugger to improve our workflow.
In general, a formalisation of critical scenarios in temporal logic has two main usages: scenario-based testing (where a vehicle controller and a scenario are given and we search for a traffic situation in which the controller behaves as specified in the scenario) and monitoring (where a driving log and a scenario are given and we search for those segments of the log which match the scenario).We note that there are a body of sophisticated tools that accept STL formulas, for scenario-based testing [1,5,32,33] and for monitoring [30].Our formalisation can be readily utilised by these tools.
Contributions.Our technical contributions are as follows.
• We provide a set of logical formulas describing traffic disturbance scenarios based on ISO 34502.• The two unique characteristics of our formalisation (namely modularity and the use of the RSS distance) suggest a general methodology for formalising various driving scenarios, beyond those in ISO 34502.• We evaluate the adequacy of the traffic disturbance scenario descriptions in ISO 34502 and propose an extension.• Experimental evaluation of our formulas demonstrates that we detect nearly all traffic disturbances in a given dataset.
Organisation.We introduce the conceptual and logical framework of our formalisation in §2 and §3.Our formalisations ISO34502-STL and ISO34502-STL-ext and the formulas used to construct them are introduced in §4.We describe the experimental evaluation of our formulas in §5, and summarise our results in §6.
Towards of our formalisation, we used our tool STL Debugger for deriving and debugging STL formulas.The tool and our use of it is discussed in Appendix B.
Related work.The RSS framework [28] is based on the assumption that all vehicles comply with pre-defined proper responses to potentially critical scenarios.In our work, we use the RSS framework to obtain a safety metric suitable to the logical formalisation of critical scenarios without the notion of responsibility implied by the proper responses.Some proper responses from [28] were formalised in STL in [11].Suitable parameter ranges for calibrating the RSS distance are studied e.g. in [13].On the use of RSS for verifying safety, recent developments are found e.g. in [10].
There are several efforts to formalise traffic rules in temporal logic, such as selected laws from the German StVO relating to interstate roads [18], dual carriageways [6], and intersections [17], as well as marine laws [16].These works formalise rules to be obeyed and thus use the always modality often, while ours is about disturbance and thus primarily uses the eventually and until modalities.
There are existing methods of detecting critical scenarios that rely on metrics such as time-to-collision (TTC) or jerk.In [22,26,34], critical scenarios resulting from cut-ins and braking are detected in monitored data.A more general workflow based on detecting critical thresholds for jerk and time-to-collision is proposed in [29].The Virtual Assessment of Automation in Field Operation (VAAFO) [31] method uses, among other metrics, a weighted sum across potential driving paths is used to identify critical scenarios where a human driver is assisted by a Highly Automated Driving (HAD) system.Our logical formalisation is independent of our specific choice of a safety metric (namely the RSS distance); use of other metrics such as TTC is well possible.That said, we believe the choice of RSS distance is another contribution of ours: it is known to be one of the advanced and robust metrics, and can easily be accommodated in temporal-logic formalisation.

PRELIMINARIES 2.1 ISO Standard 34502
ISO 34502 [12] is a proposal of safety evaluation procedures of automated driving systems, based on a joint industry effort by Japanese automotive manufacturers [27].Critical scenarios, defined in ISO 34502 as "scenario[s] including one or more risk factors", are systematically constructed in a top-down manner by combining three categories of risk factors.They correspond to the three phases in the common automated driving pipeline, namely perception, planning, and control: A perception disturbance includes intrinsic or extrinsic factors that can cause disturbance of sensors and cameras, such as light reflections or roadside objects.Traffic disturbances arise from road geometry or the behaviour of other traffic participants, such as dangerous cut-ins or braking.Vehicle control disturbances describe internal or external factors that impact the feasibility of certain maneuvers, such as vehicle weight distribution or strong winds.
By refining and systematically combining these risk factors, a large number of critical scenarios arises.This can be considered a set of reasonably foreseeable critical scenarios in which an ADV is expected to avoid collisions or minimise unavoidable accidents.
In this paper, we focus on traffic disturbance scenarios as defined in ISO 34502 for general vehicles on highways.They are composed of the following three components: The first component is road geometry: On highways, one may assume that there are no intersections, roundabouts, or unstructured roads.The relevant road shapes for highways are thus nonintersection segments (straight or curved), merge zones where two roads merge into a single road, and departure zones, where an additional road branches off the main road.
The second component is subject vehicle (SV) behaviour.It is classified into either keeping the current lane (lane keep) or changing lanes (lane change).It is assumed that all vehicles behave reasonably, hence backwards driving or U-turns are not considered.
The last of the three components is principle other vehicle (POV) behaviour: The behaviour of the vehicles surrounding SV is assumed to cause a dangerous situation for the vehicles involved.Here, these behaviours are classified into either 1) changing into the lane of SV (dangerous cut-in), 2) leaving the lane of SV (dangerous cut-out), 3) driving dangerously fast behind SV (acceleration), or 4) driving dangerously slow in front of SV (deceleration).The location of POV relative to SV is used to exclude non-critical behaviours, e.g.SV will not be endangered if POV drives faster in front of it.For critical combinations of POV behaviours and vehicle locations, see Fig. 1.
Combining these three components results in 24 traffic disturbance scenarios, see Table 1.While SV may be surrounded by several POV s, traffic disturbance scenarios can generally be composed of subscenarios involving only two vehicles, thus a formalisation of the 24 scenarios in Table 1 is the foundation of more comprehensive sets of formalised scenarios, including many-vehicle scenarios.
However, a three-vehicle cut-out is included in Table 1, namely Scenario 2: There are two vehicles ahead of SV in the same lane as SV .The POV directly ahead of SV changes lanes, whereas the other POV remains in the lane.This scenario is critical when the  remaining in the lane is slower than SV could reasonably expect, causing risk of collision.

STL
We formalise the traffic disturbance scenarios in ISO 34502 using signal temporal logic (STL) in a rigorous manner that can be used for monitoring purposes and scenario generation.STL [19] is an extension of temporal logics such as LTL (see e.g.[2]) that is designed Table 1: General vehicle traffic disturbance scenarios on highways in ISO Standard 32502 [12] (the table is from [12]).The white vehicle represents SV , the darker vehicles the POV s, the arrows indicate the (intended) motion of the vehicles.The rightmost four columns refer to POV behaviour.
to specify the behaviour of continuous-time signals in a succinct manner that nevertheless maintains readability for humans.The familiar propositional logic using the operators ¬, ∨, ∧ is extended by adding temporal operators G, F , U denoting the temporal notions always (or globally), eventually (or finally), and until.Formulas in STL are constructed inductively from the following grammar, where we let  : R  → R,  ∈ R  ,  ∈ N, and  ⊆ R an interval.
Here, the subscript  denotes the restriction of an operator to a time interval  relative to the current time.As an example, consider a formula G [2,3] ( > 5).This formula is true at time  if the value of  is greater than 5 always from time  + 2 to time  + 3.If no interval  is specified, the formula is treated as if  = [0, ∞).
The meaning of STL formulas is defined by their Boolean semantics, inductively defined in Table 2.The relationship  |=  means that the formula  is true under a signal  : [0, ∞) → R  ,  ∈ N.
Particularly important in our formalisation are the semantics of the until operator U.For a formula  1 U  2 to be true at time  , it must hold that 1)  2 is true at some time  ′ ≥  and 2)  1 is constantly true throughout the time interval [ , ′ ).Note that  1 is not required to be true at the time  ′ when  2 first becomes true; the formula  1 U  2 is thus trivially true at time  if  2 is true at time  .This becomes important in our formalisation, see §4.3.

Road Network and Vehicle Configuration
To model our road network, we use lanelets [3] and their logical formalisation in [18], so that our formulas can be applied to a wide range of road shapes.A rigorous description of our road network can be found in Appendix A.
In the current work, the relevance of lanelets is quite limited: they are used only in the very beginning of our workflow, for the purpose of mapping physical positions to lane coordinates.After that, the description of a disturbance scenario is independent of road geometry; this is seen e.g. in Table 3.In any case, here we give an informal overview of lanelets.For an illustration, see Fig. 2. Lanelets are atomic road segments described by their (piecewise straight) left and right bounds.Each lanelet has an associated attribute, denoting whether it belongs to a main road lane or to a merge/departure lane, and an associated zone, stating whether the lanelet is part of an overall merge/departure zone of the road.
A lane is then defined as the set of all lanelets of the same attribute that pre-or succeed each other.Note that by this construction, a single lane cannot branch out and lead in two different directions; however, two lanes may overlap.We call two lanes  1 and  2 adjacent if there are some lanelets  1 ∈  1 ,  2 ∈  2 , such that  1 and  2 share a boundary line but do not overlap.
We further follow [18] and model the dynamics of our vehicles as point masses described by  = (, , , ,  ) ∈ R 5 .Here  denotes the position of the vehicle along a fixed reference path Γ (typically the boundary of an outer lane),  its velocity, and  its acceleration.The lateral distance of the vehicle to Γ is denoted by , and its orientation relative to Γ by  , see Fig. 3.
For different vehicles, we use subscripts for the variables:  □ = ( □ ,  □ ,  □ ,  □ ,  □ ) for a vehicle □, where □ is typically either SV or POV ; e.g. SV is the velocity of SV .In formulas, we refer to  SV and  POV simply as SV and POV .When no confusion with the acceleration is possible, we refer to generic vehicles as  and .
To define the occupancy of a vehicle, we associate a box of length length() and width width() with each vehicle .We choose the front-left corner of this box as the point of which the location and dynamics are tracked, and define occ(, ) to be true if any part of the box associated with vehicle  is within the road segment described by lanelet , and false otherwise.Furthermore, we can define the coordinates front (), rear () as the projection of the front and rear end of the vehicle onto the reference path.By construction, we have front () =   .On highways, we may assume that road segments are locally straight, hence we assume rear () ≈   − length().
Longitudinal and lateral velocities of the vehicle relative to the reference path are given by   :=  sin( ),  lat :=  cos( ).

TRAFFIC DISTURBANCE SCENARIO FORMALISATION
We follow the modular approach of ISO 34502 ( §2.1) in our STL formalisation of its traffic disturbance scenarios for general vehicles on highways (Table 1).That is, we first fix a template of STL formulas that express traffic disturbance scenarios, and by varying the "parameters" (i.e.component subformulas) of the template, we systematically obtain the formalisation of different scenarios.
Our top-level formulas are scenario  , for  = 1, 2, . . ., 24, each of which represents one of the traffic disturbance scenarios in Table 1.The format for these formulas scenario  is the following: Here initSafe(SV, POV ) is a formula-common to all scenariosstating that there is no hazard at the start of the scenario for the duration of a pre-defined time interval; its definition is given in §4.3.The formula disturb  (SV, POV, ) expresses the content of the actual disturbance and is specific to each traffic disturbance scenario.
Here,  denotes a lane relative to which the scenario is formalised.We emphasise the importance of the formula initSafe(SV, POV ).In fact, it was absent in our early trials, causing most disturbance formulas to be trivially true for certain traces.In particular, this problem occurs with traces that either start with danger between the observed vehicles or in which the monitored interval leading up to danger is too short; we return to this discussion in §5.3.
The formula roadSector  (SV, POV ) corresponds to the road geometry component in §2.1, i.e. main road, merge zone, or departure zone.For details, see §4.6.
• The formula initialCondition  (SV, POV, ) specifies initial conditions, e.g.initial lanes and vehicle order (see Fig. 1).In some traffic disturbance scenarios (such as in Scenarios 1, 5, or 6), no such initial conditions are necessary, in which case we set initialCondition  (SV, POV, ) = ⊤.By the semantics of ⊤ (see Table 2), this subformula is thus trivially true.• The formula behaviourSV  (SV, POV, ) corresponds to the SV behaviour component in §2.1, i.e. keeping the current lane , or changing from lane  into a different lane.• The formula behaviourPOV  (POV, SV, ) corresponds to the POV behaviour component in §2.1, namely cut-in, cut-out, acceleration, and deceleration.Note that SV 's behaviour is also relevant here; the formula thus has SV as its argument as well as the lane  relative to which the behaviour of SV is described.Notably, POV behaviour formulas always contain a subformula of the form expressing that POV behaviour is dangerous relative to SV .
The overall structure of the formula disturb  (2) is as follows.It requires that a general notion of danger is true at a certain stage (recall that  1 U  2 requires  2 becoming true at some time); the formulas behaviourSV  and behaviourPOV  specify the behaviours of the vehicles in the period leading to that dangerous moment.Some additional initial conditions are expressed in initialCondition  .
There is, however, an initial condition that is common to all critical scenarios, namely that danger must happen after no danger has been observed for some time.This is entirely and exclusively described by initSafe in (1).
The STL formulas disturb  for the traffic disturbance scenarios in Table 1 are collected in Table 3.The subformulas occurring there (such as e.g.laneKeep and cutIn) are introduced in §4; after that we will review the formulas and see that they indeed correspond to the natural language descriptions in the ISO 34502 standard.
In the following section, we describe the formulas from which our formalisation of the traffic disturbance scenarios is composed.

DEFINITIONS OF FORMULAS 4.1 Vehicle Positions
We say that a vehicle  is in a given lane  if it occupies any lanelet of that lane, where occ(, ) is from §2.3.

𝑎𝑡𝐿𝑎𝑛𝑒 (𝑎, 𝐿) := 𝑙 ∈𝐿 (occ(𝑎, 𝑙)).
A vehicle  may occupy multiple lanes at once, for example during a lane change.To characterise the road sector a vehicle  is in, we refer to the zone of the lanelets the vehicle occupies, where the disjunction is indexed over all lanelets  with the corresponding

Relationship between Vehicles
We express a difference in (longitudinal) position or velocity of two vehicles  and  by

Danger
In Table 3, the formula danger (SV, POV ) is a general formula that states that POV poses a danger to SV .It is among our key findings that this formula danger (SV, POV ) can be the same in all critical scenarios-scenario-specific features can be expressed in other components of a formula.At the same time, we found that a good definition of danger is critical to the quality of our formalisation: initially we had a looser condition as danger, which matched many traces in which POV s are hardly relevant to SV (see also Appendix B).
Our definition of danger, described below, is based on the notion of RSS distance [28].It is defined as the smallest distance such that, if the lead vehicle brakes at its maximal braking rate, the rear vehicle can avoid a crash by braking at a pre-defined comfortable braking rate.According to [28] (see also [9]), the RSS distance is defined by dRSS lon (  ,   ) := max 0,    + max 2  2 ) Here,   ,   are the velocities of the rear and front vehicle respectively,  is the reaction time after which the rear vehicle starts braking,  max is the maximum acceleration of the rear vehicle,  min is the maximum comfortable braking rate of the rear vehicle, and  max is the maximum possible braking rate of the front vehicle.
For multi-lane scenarios, we additionally need a notion of lateral danger.This lateral RSS distance, following [28], is given by where Vehicle 1 is assumed to be to the left of Vehicle 2,  1 ,  2 denote their lateral velocities,  lat max the maximum lateral acceleration rate the vehicles can apply, and  lat min their maximum comfortable lateral braking rate.(For simplicity, we ignore the stability factor in [28].)Using the above functions for RSS distances, we go on to define our formulas for danger.Following the RSS framework, we define a dangerous situation as a violation of the RSS distance between two vehicles.Our main formula danger is hence defined by danger (SV, POV ) := G [0,minDanger ] rssViolation(SV, POV ); (6) it requires the formula rssViolation(SV, POV ) to last at least for the time minDanger.The time duration minDanger is a parameter that should be suitably chosen; the effect of its choice is investigated in our experiments in §5.Note that minDanger = 0 does not imply that there is no danger present; by the semantics of G [0,0] (see §2.2), it means that danger ( ,  ) is true at time  if rssViolation(SV, POV ) is true at time  ; i.e. if one chooses minDanger = 0, then danger (SV, POV ) = rssViolation(SV, POV ).
By construction, danger stands for durable danger; the notion of instantaneous danger, used in its definition (6), is defined as a violation of both the lateral and longitudinal RSS distance by rssViolation(,  ) := rssViolation lon (,  ) ∧ rssViolation lat (,  ).(7) The component formulas therein are defined as follows, using RSS distances from (4-5).

SV Behaviour
For readability we set laneKeep(, ) := atLane(, ), where  denotes a vehicle,  a lane, and atLane is from §4.1.This formula laneKeep is used as part of behaviourSV  in Table 3.

POV Behaviour
To distinguish POV 's dangerous cut-in or cut-out maneuvers from regular lane changes (see §4.4), the formulas for the former contain a term F danger to stress that these behaviours lead to danger.Furthermore, these formulas need the lane currently occupied by the SV as input.Lastly, we require that POV s complete their lane change when (or shortly after) danger occurs, in order to tie the danger to the change of lanes.This is represented by the F [0,minDanger ] (. . . ) part of the following formulas.Overall, we obtain Here, atLane is from §4.1 and sameLane and aheadOf are from §4.2.Note that by the semantics of F in Table 2, a formula of the form ) is true at time  if 1) there exists a time  ′ ≥  such that  1 is true at time  ′ and 2)  2 is true at some time during the interval [ ′ , ′ + ].
In ISO 34502 [12], it is stated that "acceleration or deceleration categories actually imply relative velocity differences with respect to the subject vehicle."We therefore define our formulas accel and decel using the fasterThan formula from §4.2.We further add laneKeep from §4.4 to distinguish this POV behaviour from the dangerous cut-ins and cut-outs defined previously.
The third component disturb  is the scenario-specific main part.Its template is given in (2) (see also the second line of Table 3).Its components initialCondition  , behaviourSV  , and behaviourPOV  are shown in Table 3.Note that the disturbance descriptions are independent of road geometry, thus it suffices to define them for the scenarios  = 1, 2, . . ., 8.
Our component subformulas initialCondition  , behaviourSV  , and behaviourPOV  for each scenario are mostly straightforward conjunctions, following their description in ISO 34502 (see Table 1 and Fig. 1).Nevertheless, the following points are worth noting.
• In Scenario 2, a three-vehicle cut-out is performed, see §2.1.Note that this maneuver cannot simply be composed of laneKeep(SV, ) and cutOut (POV 1 , SV, ), since the cutOut subformula implies danger between SV and the POV performing the cut-out maneuver (see §4.5), whereas danger in this scenario occurs between SV and POV 2 .
• In nearly all scenarios, the input lane  refers to the lane SV occupies at the beginning of the scenario.The only exception is Scenario 7, where we use the lane that SV enters as the input lane.This is due to the fact that in Scenario 7, the SV behaviour is described by the formula enteringLane rather than leavingLane, see §4.4.

Extended Formalisation ISO34502-STL-ext(A)
In our experiments ( §5), we found that natural interpretation of some of the ISO 34502 descriptions potentially overly restrictive.Specifically they concern 1) acceleration/deceleration and 2) relative vehicle positions.Our formalisation ISO34502-STL follows such natural (potentially overly restrictive) interpretation; in this section, we suggest its relaxation.We call it ISO34502-STL-ext.For experimental comparison of our two formalisations, see §5.3.The first point of relaxation is about the definition of accel and decel.We chose to include vehicle acceleration (resp.deceleration) as an alternative to relative velocity differences and define In ISO34502-STL-extA, we replace accel and decel by accel ext and decel ext .This affects scenario  ,  = 3, 4, 7, 8; all other formulas remain unchanged.
In ISO34502-STL-ext, we further extend ISO34502-STL-extA by removing aheadOf from the definition of cutIn (cf.§4.5) completely (thus redefining dangerous cut-ins to include POV entering SV 's lane behind SV dangerously), and replacing aheadOf by aheadOf ext in all other formulas.

EXPERIMENTAL EVALUATION
In this section, we seek to quantitatively evaluate our formalisation.In related work on the formalisation of traffic rules in temporal logic, experiments focussed on the percentage of vehicles in a given dataset obeying the formalised traffic rules, see e.g.[17,18].Similarly, we will evaluate our formulas on a set of recorded vehicle traces to gain insight into how often our formulas are true.
We aim to address the following research questions: RQ1 Are ISO 34502's original descriptions of traffic disturbance scenarios adequate for detecting traffic disturbances?RQ2 Are ISO 34502's original descriptions of traffic disturbance scenarios adequate for classifying traffic disturbances?RQ3 How does our formalisation perform in terms of precision and recall?RQ4 How does the choice of the duration minDanger in (6) affect the recall of our formalisation?RQ5 How does our formalisation compare to existing works, in terms of detection of common disturbance scenarios?To answer RQ3, we use two sets of ground truths.We will define them later in §5.3.

Experiment Setup
We evaluate our formulas for traffic disturbance scenarios on the highD dataset [15], which consists of drone-recorded vehicle traces on main road sections of German highways.The vehicle parameter values needed to define the RSS distance in §4.3 are chosen similarly to [11,18] as  = 0.6,  max = 5,  min = 6,  max = 8,  max,lat = 1.5,  min,lat = 1.5.We chose  min such that our RSS distance roughly corresponds to the "halber Tacho" rule-of-thumb used in Germany, stating that on highways, a safe distance (in meters) to the preceding vehicle is given by half the current velocity (in kilometers per hour); e.g. at a velocity of 100km h −1 , we consider 50m a safe distance.
In our evaluation, we first filter the data traces and focus only on those in which there arises a danger in its middle.Specifically, we first collect all pairs of cars 1 that violate the RSS distance between them eventually.Next, we evaluate the semantics of the formula dangerArises(SV, POV ) := F (initSafe(SV, POV ) ∧ F (danger (SV, POV ))).
over all vehicle pairs (SV, POV ) found in the previous step.Those traces which do not satisfy dangerArises(SV, POV ) are discarded.Since the implication scenario  ⇒ dangerArises is logically valid, the truth of dangerArises is a necessary condition for any of the formulas in ISO34502-STL(-ext) (see §4.6-4.7);therefore we are not discarding any traces that are relevant to our formalisation.We then shorten the remaining traces so that they only contain information relevant to our formulas: we discard the part before initSafe is true and the part after the last danger interval ends.Finally, we discard all data about vehicles other than SV and POV .The result of this filtering of the highD dataset is the set of traces where danger arises, i.e. those relevant to the ISO 34502 traffic disturbance scenarios.This trace set is referred to as disturbTraces.
The evaluation of our formalisations ISO34502-STL(-ext) was conducted by computing the semantics of the formulas scenario  , for  = 1, 3, 4, . . ., 8, over each trace  ∈ disturbTraces.Here, • we exclude scenario 2 since our implementation is limited to two-car scenarios (scenario 2 involves three cars and dealing with it is future work); and • we exclude scenario 9 , . . ., scenario 24 since the highD dataset only has main road traces.

Results
In our filtering of the highD dataset as discussed above, we first identified 99656 pairs (SV, POV ) between which danger according to formula (6) occurs at some point.Here we used minDanger = 0 for the formula danger in (6) to be the most inclusive.From these pairs (SV, POV ), we created two variations of the set disturbTraces, by applying the formula dangerArises in ( 14) with the following parameter values.
On these trace sets disturbTraces 1 , disturbTraces 2 , we evaluate our sets of formulas ISO34502-STL and ISO34502-STL-ext(A) (see §4.6 and §4.7).In this evaluation, the value of the parameter minDanger in the formulas scenario  is chosen to match the considered set of traces, that is, minDanger = 0 for traces in disturbTraces 1 and minDanger = 0.6 for traces in disturbTraces 2 .For the lane  in the formulas scenario  (1), we use the initial lane of POV for scenario 7 , and the initial lane of SV for scenario  ,  = 1, 3, 4, 5, 6, 8.
The results of evaluating the STL formulas scenario  on the traces in disturbTraces  ,  = 1, 2 are collected in Table 4. Using our prototype implementation, the evaluation of all formulas scenario  ,  = 1, 3, . . ., 8, over all traces in disturbTraces 1 took around 2 hours on a laptop (Windows 10, Intel Core i7 @ 2.60GHz, 16GB RAM).

Discussions
In this section, we address our previously stated research questions.
RQ1: Are ISO 34502's original descriptions of the traffic disturbance scenarios adequate for detecting critical scenarios?While the original descriptions are not adequate, our extension (see §4.7) is indeed suitable for the purpose of detecting critical scenarios.By comparing the performance of our formalisations ISO34502-STL and ISO34502-STL-extA in Table 4, it is evident that a significant number of traces are not detected with the strict interpretation of acceleration and deceleration following ISO 34502, suggesting that their definitions should be clarified.With our extension ISO34502-STLext, we detect over 96% of all traces in disturbTraces.This conclusion holds regardless of minDanger, see RQ4.
RQ2: Are ISO 34502's original descriptions of the traffic disturbance scenarios adequate for classifying critical scenarios?The descriptions are not adequate for classification purposes.This is to be expected; the ISO 34502 scenario set in Table 1 is not designed for the purpose of classification but rather for a comprehensive coverage of all traffic disturbances.As an example, consider SV keeping its lane, while POV performs a dangerous cut-in maneuver while driving at a slightly slower speed than SV throughout the maneuver.This clearly matches Scenario 1 in Table 1; however it may also match Scenario 4 if danger arises shortly after POV has entered SV 's lane.Refining the scenario descriptions (and accordingly their formalisation) for the purpose of classification is future work.
RQ3: How does our formalisation perform in terms of precision and recall?We recall the definitions of precision and recall from [24], namely precision = #truePositives/(#truePositives + #falsePositives), and recall = #truePositives/(#truePositives + #falseNegatives).For our experiments, a true positive denotes a disturbance trace for which one of our formulas is true, a false positive is a disturbancefree trace for which one of our formulas is true, and a false negative denotes a disturbance trace for which none of our formulas are true.Precision and recall for individual scenario-formulas are outside the scope of our experiments, as this would require the dataset to contain labels denoting the type of traffic disturbance scenario.
We have a precision of 100%-false positives cannot occur in our formalisation, as our definition of a disturbance trace as a trace for which the formula dangerArises (see §5.1) is eventually true has been exactly implemented into all our formulas.
The recall of ISO34502-STL, and particularly of ISO34502-STL-ext, relative to the sets disturbTraces  ,  = 1, 2 is very high, see Table 4.This notion of recall is exactly what we discussed in RQ1.
We note that the use of initSafe (see §4.3) is important.Indeed, if we omit the filtering using dangerArises (14) and merely filter Table 4: Quantitative results of our experiments.Data trace set T refers to the set of traces on which our formulas are evaluated.See §5.1: disturbTraces 1 , disturbTraces 2 are the sets with minDanger = 0, 0.6, respectively.The number of traces in  is denoted by | |.In the spec set column, the evaluated set of formulas is noted (see §4.6 and §4.7).Matching traces denotes the total number of traces in  for which at least one of the considered formulas scenario  ,  = 1, 3, . . ., 8 is true.The recall column (see §5.3) refers to recall relative to | | as ground truth.In each column labelled   ,  = 1, 3, . . ., 8, we state for how many traces in  the corresponding formula scenario  is true.using danger (6), our recall is quite low (around 25%) due to many false negatives.This is natural; due to the spatial limitation of the highD dataset, many traces do not fulfill initSafe, i.e. danger is either present from the beginning of the trace or the observed interval of safety leading up to danger is shorter than required by initSafe.This spatial limitation can be considered a perception disturbance (see §2.1), which is outside the scope of our formalisation.RQ4: How does the choice of minDanger in (6) affect recall of our formalisation?
The choice of minDanger in (6) does not have a significant impact on recall, see Table 4.For this reason, we restrict our discussion of the other research questions to minDanger = 0.
One implication of the above is that our formalisation-based on the RSS-based notion of danger-is stable, with respect to a parameter value which is not easy to choose (namely minDanger).
RQ5: How does our formalisation compare to existing works, in terms of detection of common disturbance scenarios?
Here we compare the content of our formalisation with some existing works.We focus on the cut-in and deceleration scenarios, as these two scenarios have been studied many times before.Our comparison is with [26] (with two danger metrics TTC and THW) and [34], as these works evaluate their formalisation on the highD dataset.The comparison is in Table 5; here are some details.
In [26], a cut-in is defined as a lane change in which POV enters the lane of SV in front of SV .The notion of deceleration is defined in [26] as hard braking (above a parameter value they choose) by the POV ahead of SV in the same lane.As danger metrics, time to collision (TTC < 4s) and time headway (THW < 2s) are used.
In [34], a cut-in is defined as in [26], with the additional restrictions that 1) the lateral velocity of POV must remain nonzero throughout the maneuver, and 2) a maximum longitudinal distance between SV and POV is introduced.A deceleration scenario is defined as "reduction of the headway distance between vehicles [...] caused by the deceleration of a preceding vehicle and not by the acceleration of the subject vehicle", where POV is required to brake continuously throughout the scenario and to remain in its lane.In [34], matching traces are first detected without any danger metric; later the danger metrics TTC and THW are calculated for the detected traces.We restrict our discussion to the number of traces that were detected without any danger metric, as their danger metric analysis lacks absolute numbers.
For our formalisation, we use ISO34502-STL-ext ( §4.7), based on our discussion in RQ1.We identified cut-in as Scenario 1 and deceleration as Scenario 4: although Scenarios 5 and 8 also contain cut-in and deceleration components, respectively, Scenarios 1 and 4 correspond more closely to the definitions used in [26,34].The numbers for ISO34502-STL-ext in Table 5 are hence the numbers for Scenario 1 (cut-in) and Scenario 4 (deceleration) from the third row of Table 4, i.e. for minDanger = 0 and ISO34502-STL-ext.
In Table 5, the numbers for different formalisations for both the cut-in and deceleration scenarios are quite different.For each scenario, the number for our formalisation is (close to) the greatest, and we may wonder if the number is too large.We argue that this is not the case: • the trace set disturbTraces 1 is a naturally defined one by the formula dangerArises in ( 14); • the whole set ISO34502-STL-ext of formulas, achieving 96.1% recall for disturbTraces 1 (see RQ3), is therefore a natural one (note that precision is 100% by definition); and • the formulas scenario 1 and scenario 4 , defined by imposing natural constraints (Table 3), are natural ones, too.
We note that a similar number of cut-ins as in our experiments is detected in [26] (7219).This is natural, since their danger metric THW < 2s is very similar to the "halber Tacho" rule we used to calibrate our parameter values for the RSS distance (see §5.1) and their definition of a cut-in is similar to ISO 34502.On the other hand, [34] detects significantly less cut-ins (1017) even without a danger metric; this may be due to the restriction on the longitudinal distance between the two vehicles.
For deceleration scenarios, [34] detects a very similar number (26846) as our formalisations.Note that in [34], no danger metric is used, implying that deceleration on highways leads to a violation of the RSS distance (see §4.3) in nearly all cases.On the other hand, the formalisation in [26] is much stricter and hence matches significantly fewer traces (< 150).
Another point in the comparison is that parameter-tuning is easy in our formalisation.Our parameter-tuning is largely reduced to that for RSS in general: • besides the RSS parameters (e.g.response time  and maximum acceleration/braking rates, see §4.3), our formalisation only has minDanger and minSafe as parameters, and • as seen in RQ4, the value of minDanger is hardly relevant.
Tuning the RSS parameters is a more general problem-those parameters are important beyond specific disturbance scenarios-and methods of doing so are an active field of research [13].Such ease of parameter tuning is not the case, e.g. in [26], where "hard braking" in a deceleration scenario must be manually defined.

CONCLUSIONS AND FUTURE WORK
In this paper, we presented a temporal logic formalisation of traffic disturbance scenarios concerning general vehicles on highways as specified in ISO Standard 34502.Based on this important class of scenarios, further critical scenarios can be formalised through a modular approach.Our formalisation relies on the RSS framework, allowing for easy parameter-tuning.Experimentally, we were able to show that a small extension of the ISO standard allows for a very high rate of disturbance trace detection.
Future work includes the formalisation of further critical scenarios in ISO 34502 and beyond, such as scenarios involving motorcycles, vehicle control disturbances, and intersection scenarios.
Our current formalisation needs an initial lane as input, since STL does not support variable binding and hence does not allow us to refer to the lane initially occupies otherwise.As future work, an implementation of our formulas to an extension of STL with temporal freezing (e.g.STL*, see [4]) should be considered.
before and  after -exemplifying  before ∧ ¬ after (or its negation) synthesises a signal that resides in their semantical difference.

C ROBUST SEMANTICS
Besides the standard setting of (qualitative) Boolean truth values, a quantitative robust semantics is also widely used.In robust semantics, truth values are real-valued numbers, where 1) a positive value stands for true and a negative value for false; and 2) their absolute values stand for the margins of being so.These semantics are defined inductively in the same manner as the Boolean semantics; see e.g.[7].Robust semantics have the advantage of not only telling us if a formula is true, but also including information about how robustly a formula is true.
Remark.It is natural to use robust semantics (cf.§2.2) for the formula rssViolation (7) to measure the degree of danger.The above definition of the formula, however, is not suited for the purpose.It violates a natural monotonicity property-between the robust semantics and the inter-vehicle distance-due to a specific way of interpreting ∧ in robust semantics.(The interpretation of Boolean connectives such as ∧ is a general problem in robust semantics.See e.g.[33].) A possible fix is to use the following formulas.They are equivalent to the above definition in terms of signs (thus Boolean truth), but are better behaved with respect to quantitative robust semantics as defined in §2.

Figure 1 :
Figure 1: Left: Numbering of possible POV locations relative to SV .The fields numbered as "+1" are only relevant in three-vehicle scenarios.Right: Combinations of POV positions and behaviours that may cause critical scenarios.These are from [12].

Figure 2 :
Figure 2: A sample road section (departure zone) constructed from lanelets forming two main road lanes (grey, attr () = main) and one departure lane (blue, attr () = departure).All depicted lanelets satisfy zone() = departZone.The driving direction is indicated by the arrow.The departure lane is adjacent to the lower main road lane but not adjacent to the upper main road lane.

Figure 3 :
Figure 3: Curvilinear coordinates, with the reference path Γ being the lower road boundary.Here,   denotes the coordinate of the vehicle  along the Γ,   the distance of  from Γ, and   the orientation of the vehicle relative to Γ. See Section 2.3 for the definition of rear ().

Table 5 :
[34]34]e number of the cut-in and deceleration scenarios detected in the highD dataset by[26,34]and our formalisation (see §4.6-4.7).Definitions and danger metrics of[26]and[34]are discussed in the discussion of RQ5 in §5.3.Our danger metric RSS distance is defined in §4.3.The values in the ISO34502-STL(-ext) columns are from Table4.For details see the discussion of RQ5 in §5.3.