Generation of Complex Road Networks Using a Simplified Logical Description for the Validation of Automated Vehicles
GGeneration of Complex Road Networks Using a Simplified LogicalDescription for the Validation of Automated Vehicles*
Daniel Becker , Fabian Ruß , Christian Geller and Lutz Eckstein c (cid:13) Abstract — Simulation is a valuable building block for theverification and validation of automated driving functions(ADF). When simulating urban driving scenarios, simulationmaps are one important component. Often, the generation ofthose road networks is a time consuming and manual effort.Furthermore, typically many variations of a distinct junctionor road section are demanded to ensure that an ADF can bevalidated in the process of releasing those functions to thepublic.Therefore, in this paper, we present a prototypical solutionfor a logical road network description which is easy to maintainand modify. The concept aims to be non-redundant so thatchanges of distinct quantities do not affect other places in thecode and thus the variation of maps is straightforward. Inaddition, the simple definition of junctions is a focus of thework. Intersecting roads are defined separately, are then set inrelation and the junction is finally generated automatically.The idea is to derive the description from a commonlyused, standardized format for simulation maps in order togenerate this format from the introduced logical description.Consequently, we developed a command-line tool that generatesthe standardized simulation map format OpenDRIVE.
I. I
NTRODUCTION
In recent years, the interest in autonomous driving hasconsiderably increased, both in research and society. Toensure the safety of automated driving functions (ADF),verification and validation methods need to be developedand established. The approval of an ADF for public roadtraffic demands compliance with safety requirements regard-ing its functionality. The requirements include an error-freebehavior over several billion test kilometers. For exampleWachenfeld and Winner [1] state that the distance to prove aninterstate pilot amounts to 6.62 billion test kilometers, with atheoretically 50% chance this prove would say that the ADFis twice as good as a human driver. Since this distance seemsunreal and economically not acceptable, Schuldt [2] advise ascenario based-testing. In order to shorten the test time, savecosts and detect functional errors at an early developmentstage, simulation is well suited. It is also appropriate tocreate any number of scenarios and to explore critical drivingsituations without endangering people. *This research is funded by the SET Level 4to5 research initiative, pro-moted by the Federal Ministry for Economic Affairs and Energy (BMWi). Daniel Becker and Fabian Ruß are with the automated drivingdepartment of the Institute for Automotive Engineering (ika), RWTHAachen University, 52074 Aachen, Germany { daniel.becker,fabian.russ } @ika.rwth-aachen.de Christian Geller is with RWTH Aachen University, 52062 Aachen,Germany [email protected] Lutz Eckstein is head of the Institute for Automotive Engi-neering (ika), RWTH Aachen University, 52074 Aachen, Germany [email protected]
Fig. 1: Graphical example of input and output of the roadgeneration tool. As a minimal input, two reference lineswith assigned road types and a coupling point are sufficientto generate an intersection written in valid OpenDRIVE,visualized in CarMaker 8.0 .Scenario-based testing introduces three different stagesto describe scenarios systematically: functional, logical andconcrete, cf. [3]. The term functional states a linguisticdescription which allows experts to talk about scenarios at anearly stage of the development process. In logical scenarios,parameters and ideally their probability distributions areprovided. Finally, concrete scenarios specify a distinct valuefor each parameter which makes them feasible to be executedreproducible in a simulation or on proving grounds.This kind of description uses the subdivisions of the six-layer model described by Bock et al. in [4], which is basedon the layer model in Schuldt [2]. In this model, a scenario isdivided in basic components and only an interaction betweenall the six layers represents a complete scenario. The modelis illustrated in Fig. 2. The three lower layers describe thestatic part of the scenario. Layer four focuses on movingobjects, whereas layer five and six describe environmentalconditions and vehicle-to-everything (V2X) communication,respectively. Detailed discussion of layer four on Germanmotorways can be found in Weber et al. [5].Besides layer four which describes the dynamic behaviorof all traffic participants, the static scenery has to be takeninto account as well. The latter consists of the road networkand all non moving objects which are relevant for thescenario. As mentioned, it is described within layer one tothree of the six layer model and has to be defined in alogical and concrete manner, respectively. The open sourcestandard format OpenDRIVE [6] is suitable for concretedescriptions of road networks and is widely used in industryand research. However, by now there is no standardizedlogical road description format which is easy to use andcapable of being transferred into OpenDRIVE. https://ipg-automotive.com/de/produkte-services/simulation-software/ a r X i v : . [ c s . OH ] J un ayer 6Layer 5Layer 4Layer 3Layer 2Layer 1 Fig. 2: The data layers for the description of a scenariofollowing [4] and [7].Current research initiatives such as SET Level 4to5 whichis funded by the Federal Ministry for Economic Affairs andEnergy (BMWi) of Germany, address simulative scenario-based testing with a focus on inner city traffic. Consequently,the concept presented in this paper aims to offer a descriptionfor road networks which allows easy modifications of themap due to a non-redundant design. Further, it is possibleto provide limited information for intersections and lanedefinitions since some default configurations and dependen-cies for main and access roads are defined. The input shallbe translated into a concrete standardized road descriptionformat. Therefore, with the logical description comes aroad generation tool that calculates all required OpenDRIVEquantities from the simplified input. We use XML to storethe input and the corresponding OpenDRIVE output is savedin XML as well. This way we attempt to close a gap in thepipeline of defining logical scenarios on intersections andmake them executable in a concrete manner.An example which outlines the idea of the concept isshown in Fig. 1 where an X-junction is defined by a mainroad intersected by an access road as the input and the resultis a verified OpenDRIVE map which can be used in commonautomotive simulation software.The remainder of this paper is organized as follows. First,Sec. II introduces related work to the topic, followed bySec. III where input format is described in more detail. Then,details on the implementation are documented in Sec. IV.Next, in Sec. V several results are presented and finally aconclusion and outlook is given in Sec. VI.II. R
ELATED WORK
During the research initiative PEGASUS [8] the conceptsof scenario based testing have been developed and utilized within the domain German motorway. Furthermore, the mainfocus has been on layer four. Motorways usually consistof parallel lanes which follow curves with big radii. Sucha road is not complicated to describe and generate. It canbe done automatically with low effort. Menzel et al. [9]propose a method to create a standardized road network inthe OpenDRIVE format from a logical (and functional) roaddescription. A similar approach has been done by Noyer etal. [10] who created a format called SimplifiedRoad which isan XML schema to describe long streets without junctions.This logical description is primary meant to easily createconcrete highway sections and cannot specify all details inOpenDRIVE. However, when moving the testing domainto inner city scenarios such as the driving behavior onintersections, layers one to three (cf. Fig. 2) are much morecomplex both in the logical description and in terms of theconcrete format.There are basically two different ways of creating virtualroads for simulation in the industry. In the first variant, thestreets are build based on recorded real data. Disadvantagesare the effort of collecting sufficient information of roadnetworks and the restricted possibility in track variation.Examples for such systems are Road2Simulation presentedby Richter and Scholz in [11] and services of the companyatlatec . The second variant is based on the manual creationof a the track with a visual track editor. This way, auser is required to assemble the road manually. Examplesof such systems are Road Designer [12], CarMaker (IPGAutomotive) and others. Those tools are useful for creatingdistinct road networks in an easy to use way but an automatedgeneration of a huge number of similar road networks is hardto realize. III. L OGICAL ROAD DESCRIPTION
The proposed logical road description is derived fromthe reference line concept used in OpenDRIVE [6]. Thismeans that each lane is described by an offset from areference line defined in the x , y -plane (topview). However, incontrast to OpenDRIVE we introduce some simplificationsand eliminate redundancies along the reference line. Eachroad segment consists of the geometric primitives line, arcand spiral, which is motivated by the federal guidelines forroad constructions in Germany cf. [13] and [14]. A simplifiedillustration of the road network’s XML structure is shownin Fig. 3. On the first level under the roadNetwork tagall segments are defined and links which connect themcan be stated (node ”seg. assembly”). In addition, ”looseends” of segments can be automatically connected within the closeRoadNetwork tag. As illustrated, segments mightbe T-/X-junctions, roundabouts and connection roads.In the following sections, the reference line is examined inmore detail, followed by the description of the input for thelogical road network concept. The documentation is basedon the nodes shown in Fig. 3. oad networksegmentsseg. assembly close road netw. roundabout connection roadT / X junction rr r Ir r r I Fig. 3: Hierarchical structure of the road network. On the firstlevel all segments and their relation to each other are defined.In addition, it is possible to define the automatic connectionof two road ends. Segments are defined as roundabouts,junctions and connection roads. r i and I describe roads andintersection definitions, respectively. A. Reference Lines
In order to ensure a smooth driveability along the roadnetwork, we define that the curvature has to be continuousalong roads where curvature is defined as the reciprocalof the radius. Therefore, the definition of curvature overdistance, a start point and initial heading is sufficient touniquely describe a road’s course. At the same time, thisimplies that in contrast to OpenDRIVE it is not necessary tostate the start point and heading of each geometric element(i.e. line, spiral, arc). Fig. 4 shows the definition of aroad segment that is composed of the geometric primitivesequence line-spiral-arc-spiral-line.As shown in Fig. 4 a), the curvature κ ( s ) is a piecewiselinear defined function over distance. Since we use lines,spirals and arcs, three definitions for those pieces are re-quired. A line is described by κ ( s ) = L needs to be specified. An arc’s course is defined bya constant curvature κ ( s ) = κ arc = const. Therefore, an arcis defined by a length L and a radius R . Note that we useradii in the input description because they are more intuitivethan the curvature. Finally, a spiral is characterized by alinear change of curvature: κ ( s ) = as , where a is constant(for details on spirals cf. [13]). Consequently, in addition tothe length L , the start and end radius R s and R e need tobe defined for a spiral to be unique. Those definitions arethen being concatenated to a curvature graph and result inan unambiguous road course in the x , y -plane as in 4 b),if either the initial values for position and orientation at thestart are provided or the road is connected to another segmentwithout a curvature jump. B. Segments
In the following, the segments which might be defined inthe road network input are described starting with connectionroads, followed by junctions and roundabouts.Connection roads consist of single road tags definedby a reference line and definition for lanes and signals inthe s , t -coordinate system. The latter is a moving coordinatesystem along the distance s . The t -coordinate is defined asthe offset orthogonal to the reference line at position s . Lane a) 𝜅 [1/m] 𝑠[𝑚] 𝑦 [m] 𝑥[𝑚] spiralline arc b) Fig. 4: Qualitative example for a curve defined by thecurvature graph. The plan view results from two integra-tions over s . Geometric primitives: line-spiral-arc-spiral-line.Positive curvature values correspond to left turns in positive s direction.extension and merging follow 3rd-degree polynomials whichare stated by their start and end point in s , t -coordinates, thecorresponding polynomial coefficients are calculated by theroad generation tool.At least two and at most three road entities are requiredto create a T-junction. Often one road is the dominant ormain road in an intersection, which can be exploited bydefining it as a single road that is intersected by an accessroad. Alternatively, three single roads can be combined toform a T-junction by defining one reference road and theangles at which the other two roads are connected. The mainidea of the intersection concept is that each road is definedin its own local coordinate system (cf. Fig. 5 a)) and iscombined afterwards, as shown in Fig. 5 b). E.g., the T-junction in Fig. 5 consists of a main road described by anarc and an access road whose course follows a line. Themain road is intersected by the access road approximately atits center ( s ) whereas the additional road is connected at itsorigin ( s =
0) under the angle α . The reference coordinatesystem of the segment now is at the junction’s center withthe x -axis parallel to the tangent of the main road at thispoint. The described road combinations are defined within intersectionPoint -tags which are part of the I -knotsof Fig. 3.In addition to topological information of the junction, itis possible to define the intersection area more detailed ina coupler -tag. First, for each road arm the distance fromthe intersection point to the beginning of the junction can bespecified. The latter means the point where turning lanes startto leave the course of the reference line. They are specifiedby their minimal radius, the concrete course is calculatedautomatically (cf. Sec. IV-B). Fig. 7 shows the concept ofthe intersection area. Furthermore, additional lanes for leftand right turns can be added ad libitum. The descriptionsof T- and X-junctions are a lot alike and thus X-junctionscan be created analogously to the preceding paragraph aboutT-junctions.Roundabouts are defined similar to junctions with thedifference that the reference road is of circular form (fornow a circle) and every access road is assigned at a position s with an angle α to this reference element. = 0 𝑠 a) b) 𝑦 𝑦 𝜅, 𝐿 𝑎 𝐿 𝑙 𝛼𝑥 𝑥 𝑦 𝑥 Fig. 5: Two roads are coupled to form a T-junction. Road 1 isdefined as an arc by length and curvature whereas road 2 isa straight line with length L l . On both roads the intersectionpoint along s is defined. In addition, the angle α at this pointis stated. a) b) 𝑦 III III 𝑥𝑦 𝑥𝑥offset 𝑦offset𝛼offset
Fig. 6: Three segments are concatenated to form a roadnetwork. First, one reference segment has to be set (I).For further connections only the two endpoints need tobe specified because concatenation follows the continuouscurvature condition.
C. Combine Segments
Once all desired segments are specified, those may beconcatenated to form a road network. In general, all segmenttypes can be combined with each other. The only conditionis that the curvature at the connection point is mutual tofulfill the continuous curvature condition we introduced forreference lines. However, in the current state of the roadgeneration tool the curvature has to be zero at the connectionto combine two segments. Fig. 6 illustrates the combina-tion of an X-junction, connection road and T-junction. Inthis example, segment I provides the reference coordinatesystem which can be placed at any position and orientation x offset , y offset and α offset in world coordinates. Next, the con-nections between I and II as well as II and III are defined ina linking tag by stating which segment endings are linked.With this information, the road generation tool is able togenerate an OpenDRIVE map uniquely.One more option of the road network concept is theautomated generation of a compound curve (composed oftwo spirals with an arc between them) to close the gapbetween two loose road ends. This might be required ifthe road network should be used for endurance simulationswhere traffic agents shall drive in circles infinitely often and no sources and sinks are implemented in the simulationenvironment. It is not possible to calculate a curvature graphwhich matches a desired endpoint in the x , y -plane froman known start point analytically because of the algebraicproperties of spirals (cf. Sec. IV-A). Therefore, an optimiza-tion problem needs to be solved which attempts to findcombinations of segment lengths s i and a radius R whichform a curve similar to Fig. 4 that matches the desired endpoint with κ = OAD GENERATION
The specified input may be translated into the road net-work standard format OpenDRIVE by a command-line tool.Since the input describes a simplified representation of theroad network, missing information needs to be calculated toprovide a verified OpenDRIVE map. In the following, somesteps of these calculations are described starting with detailson geometric properties of roads and lanes followed by thegeneration of intersections.
A. Geometry
As introduced in Sec. III-A, we assume that a road’sreference line is curvature continuous and therefore, a singleinitial position and heading is sufficient to calculate itscourse. However, OpenDRIVE requires a start point andheading for each line, arc or spiral. In order to provideinformation on x , y -coordinates and orientation ϕ for eachgeometric primitive, a transformation depending on the ge-ometry type is necessary. For a straight line, the followingtrivial equations result: ϕ ( s ) = ϕ , x ( s ) = s cos ( ϕ ) , y ( s ) = s sin ( ϕ ) . (1)With a segment of a circle, however, the orientation alsochanges along s . With constant curvature κ and the angle ϕ ( s ) = s κ + ϕ this results in: x ( s ) = κ ( sin ϕ ( s ) − sin ϕ ) y ( s ) = κ ( cos ϕ − cos ϕ ( s )) . (2)For a spiral the coordinates along s can be described with aparameter a = √ Rs = (cid:113) κ s which is constant at any point ofthe spiral (cf. [13]) and the following equations hold: x = a (cid:90) as cos (cid:0) t (cid:1) dt , y = a (cid:90) as sin (cid:0) t (cid:1) dt . (3)The formulas in (3) are called Fresnel integrals and it can beshown that there is no analytical solution for them. However,they can be approximated by a power series expansion forsine and cosine. With help of (1) to (3) missing informationfor each reference line can be calculated such that Open-DRIVE requirements are fulfilled.In a further step, lanes are added to the reference line. Eachis described by a lane type, a marking, and especially by awidth w , which for each lane i corresponds to a polynomial w i ( s ) = as + bs + cs + d with coefficients a , b , c , d . Thewidth for each lane is defined separately and the finalouter t -coordinate of the road results from the sum of all ) b) c) d) Fig. 7: From logical definition to concrete intersection. Afterthe reference lines are in the correct position a), correspond-ing lanes are generated (b). Subsequently, the intersectionarea is cut free (c) and all required connection lanes aregenerated automatically (d). w i ( s ) . Lanes are divided into lane sections in which thosepolynomials are valid. Note that the s coordinate is zero atthe beginning of a road but not at the beginning of a lanesection. In the simplest case, w is constant and a = b = c = , d = w holds. If a lane widening occurs, the lane widthincreases from w i ( s ) = w i ( s + ds ) = w over a given length ds . Additional conditions for modelingthe four polynomial coefficients are continuous transitions ( w (cid:48) i ( s ) = ) at start and end of the widening s and s + ds ,respectively. This case, the four coefficients can be uniquelysolved with help of the described conditions. A lane lapsebehaves analogously but starting with w i ( s ) = w and endingwith w i ( s + ds ) = B. Intersections
Besides the reference lines, the intersections and round-abouts specified in the input file have to be processed inorder to form valid OpenDRIVE entities. Each intersectionor roundabout consists, as shown in Fig. 3, of correspondingroads r i as well as more detailed information I . Besides thesize of the intersection area, it is also specified which lanesof the individual roads are connected or whether additionallanes are added before the intersection.A segment is constructed such that the junction midpointlies in the origin and intersects the reference road withoutany angle. Further roads r i intersect the origin at the specifiedroad position s I,i at a defined angle α I,i , so that the startingpoint and the starting angle of each geometry of this roadmust be shifted by a translatory offset ˜ x , ˜ y and rotated aroundthe angle ˜ ϕ = α I,i . The translatory offset can be determinedfrom the coordinates at position s I,i so that all segments withtheir starting points x , y , ϕ can be transformed as follows. x = cos ( ˜ ϕ ) ( x − ˜ x ) − sin ( ˜ ϕ ) ( y − ˜ y ) y = sin ( ˜ ϕ ) ( x − ˜ x ) + cos ( ˜ ϕ ) ( y − ˜ y ) ϕ = ϕ − ˜ ϕ . (4)Before inserting new connecting roads, the junction areahas to be generated, which requires a cut in the reference A BI H β (a) find helping point A B r d β (b) arc construction A B (c) connected road
Fig. 8: Process for connecting roads in junction area.line of each road r i . From the junction midpoint at s I,i wedefine s A as the length along s which spans the junction areain one direction. Note that for simplicity we assume s A inboth directions of the reference line in the documentation. Inpractice those are two variables. From the defined referenceline of r i , two parts are extracted: the part up to the beginningof the junction ( − inf , s I − s A ] and the part behind the junction [ s I + s A , inf ) . The two relevant parts of the reference line arenow iteratively copied over all geometries to generate thenew exit roads of the intersection. Depending on the cut ofa straight line, arc or spiral, the respective segment of thereference line has to be adapted. The result of this step canbe illustrated as shown in Fig. 7 c).After every street is cut and correctly positioned, the nextstep is calculating the reference lines of the lanes inside ofthe intersection area. Each lane is generated as an individualstreet with its reference line, whereby the single-lane liesto the right of the reference line. Based on starting point A and endpoint B as well as the angles ϕ A and ϕ B the newreference line of a lane is calculated. As a simplification,only straight lines and arcs are used since the discontinuityin the curvature can be neglected at low speeds. Note thatthe assumption still yields continuous angles along s . Thesetup for one connection road is illustrated in Fig. 8. A isthe end of the road entering the intersection area and B isthe corresponding start of the newly generated road leavingthe junction. In the following, the geometric construction ofthe new reference line is described.In the first step, the endpoints are extended with straightlines to calculate the intersecting point I . I x = B y − A y + ( tan ( ϕ A ) A x − tan ( ϕ B ) B x ) tan ( ϕ A ) − tan ( ϕ B ) I y = tan ( ϕ A ) · I x + ( A y − tan ( ϕ A ) A x ) . (5)The euclidean distances d A = (cid:107) A − I (cid:107) and d B = (cid:107) B − I (cid:107) between endpoints and intersection point are then beingcalculated and the road with greater distance is extended bya line until the new distances are equal, which introduces thenew helping point H at the end of the extended line. Finally,the two points are connected by an arc with radius r andlength l . The following equation determines the parametersig. 9: OpenDRIVE output of a road network generated by the tool which processes the developed logical road description.The road network consists of three junctions, one roundabout, one connection road and four automatically generated roadnetwork closing roads. Visualization with internal Unity tool.of the circle, where β = ϕ B − ϕ A : r = (cid:113) ( H x − A x ) + ( H y − A y ) · sin (cid:16) β (cid:17) l = | r · ( ϕ B − ϕ A ) | . (6)This procedure is repeated until all connection roads, i.e.connection lanes, inside the junction are calculated.V. R ESULTS
Recall Fig. 1, which shows a generated X-junction. Theinput description of this map consists of 32 lines whereas theresulting OpenDRIVE file is 870 lines long. This shows onebenefit of the proposed road description which is straightfor-ward to maintain.In Fig. 10 the OpenDRIVE output of two concatenatedT-junctions is shown. Each segment consists of a main roadwhich follows an arc and one access road that is modeledas a straight line. The angle between both roads is α = π .Further, a link between both junctions is applied at the end ofthe respective access road. Both junctions are defined mostlythe same, the only differences for the upper junction are thatthe radius of the main road is smaller and that an optionis activated which automatically generates lane wideningsfor left turns on main roads. In fact, only two chars aredifferent in the respective junction definitions which makesthe description easy to vary. In addition, the input file consistsof four defined roads whereas the resulting OpenDRIVE filecontains 18 road definitions. These effects have impact onthe overall amount of code which can be seen in Table Iline 2. The input file requires only 5 .
3% as many chars asthe concrete OpenDRIVE file.As a general overview, in Fig. 9 the result for a con-siderably large road network is illustrated. It is describedentirely by the presented logical description and then isinstantiated as OpenDRIVE with help of the developed tool.The network consists of three intersections, one roundabout,one connection road and four instances of the close roadnetwork function which generates compound curves betweensegments automatically. As shown in Table I line 3, the inputfile is significantly smaller in terms of code length than theresulting OpenDRIVE file. In addition, only little parts of https://unity.com/ Fig. 10: OpenDRIVE Output of two concatenated T-junctions. Both junctions are almost identically defined. Theonly differences for the upper junction are that the radius ofthe main road is changed and an option that automaticallygenerates lane widening for left turns is activated. Notethat black lines indicate lane courses, not their marking.Visualization in CarMaker 8.0.TABLE I: Comparison of OpenDRIVE and logical descrip-tion in terms of amount of code.
File OpenDRIVE Logical DescriptionLines Chars Lines CharsXJunc (Fig. 1) 870 32 ,
468 3 .
7% 4 . ,
414 5 .
0% 5 . ,
477 210 ,
215 4 .
0% 4 . the input have to be changed (e.g. the curvature of oneconnection road) in order to obtain a road network of similartopology but with thousands of changes in the OpenDRIVEfile. This way, parameter spaces for distinct quantities may beexplored and many concrete road networks can be generatedusing one logical definition.All generated OpenDRIVE files are verified against cur-rent OpenDRIVE XSD schemas of version 1.4 and 1.5 . Inaddition, we evaluated selected tracks with ODR Viewer , arMaker 8.0 and RoadRunner by making sure the importworks, the visualization is plausible and a vehicle is able topass the generated track.VI. C ONCLUSION AND OUTLOOK
In this paper, we introduced a prototypical concept to de-scribe road networks in a logical manner with the possibilityto generate a standardized concrete format which can be usedin most simulation environments. The results are ready to usesimulation maps which can be easily varied.A next step could be the analysis of real road networks tocalibrate the assumed parameters, e.g. for main and accessroads or radii and width of lanes inside junctions. Further,the logical input and road generation tool might be extendedwith more features such as nested junctions or objects next tothe road. In addition, the concatenation of segments could beimproved. Curvatures unequal to zero might be allowed at theconnection between two segments, or the close road networkfunction could be enhanced such that linking elements amongtwo junctions can be generated automatically.R
EFERENCES[1] W. Wachenfeld and H. Winner, “The release of autonomous vehicles,”in
Autonomous driving . Springer, 2016, pp. 425–449.[2] F. Schuldt, “Ein Beitrag f¨ur den methodischen Test von automatisiertenFahrfunktionen mit Hilfe von virtuellen Umgebungen,” Ph.D. disser-tation, 2017.[3] T. Menzel, G. Bagschik, and M. Maurer, “Scenarios for development,test and validation of automated vehicles,” in . IEEE, 2018, pp. 1821–1827. , 2018.[5] H. Weber, J. Bock, J. Klimke, C. Roesener, J. Hiller, R. Krajewski,A. Zlocki, and L. Eckstein, “A framework for definition of logicalscenarios for safety assurance of automated driving,” Traffic InjuryPrevention , vol. 20, no. sup1, pp. S65–S70, 2019, pMID: 31381437.[Online]. Available: https://doi.org/10.1080/15389588.2019.1630827[6] M. Dupuis, E. Hekele, and A. Biehn,
OpenDRIVE Format Specifi-cation, Rev. 1.5 , 1st ed., VIRES Simulationstechnologie GmbH, Feb2019.[7] G. Bagschik, T. Menzel, and M. Maurer, “Ontology based scenecreation for the development of automated vehicles,” in . IEEE, 2018, pp. 1813–1820.[8] J. Mazzega, “Pegasus method: An overview,” Lilienthalplatz 7, 38108Braunschweig, Germany, May 2019, contributions: PEGASUS ProjectPartners.[9] T. Menzel, G. Bagschik, L. Isensee, A. Schomburg, and M. Maurer,“From functional to logical scenarios: Detailing a keyword-basedscenario description for execution in a simulation environment,” in . IEEE, 2019, pp.2383–2390.[10] U. Noyer, A. Richter, and M. Scholz, “Generation of highwaysections for automated test case creation,” in
Driving SimulationConference Europe 2018 VR , A. Kemeny, F. Colombet, F. M´erienne,and S. Espi´e, Eds., 2018, pp. 171–174. [Online]. Available:https://elib.dlr.de/117113/[11] A. Richter and M. Scholz, “Deploying guidelines and a simplified datamodel to provide real world geodata in driving simulators and drivingautomation,”
Transportation Research Part F: Traffic Psychology andBehaviour , Mai 2017. [Online]. Available: https://elib.dlr.de/110094/[12]
ROD - Road Designer - Product Data Sheet , VIRES Simulationstech-nologie GmbH, Grassinger Strae 8, 83043 Bad Aibling, Germany, June2013.[13] R. Baier,