Generation of Highway Sections for Automated Test Case Creation

Kurzfassung

Creating proper tracks for simulation including logical representation is usually a demanding, time consuming, iterative and manual task using classical visual scenario editors. On the contrary, creating and managing multiple variants of tracks varying in details is needed to build virtual test cases, which become especially important with regard to automated driving and its enormous test requirements. From this background manual test scenario creation becomes quickly overwhelming. Consequently, approaches for automated creation of tracks for testing purposes are needed. This paper presents a solution to create various tracks automatically covering a huge variety of characteristics. It uses a lightweight description to minimize definition effort done either manually or derived methodologically . This work is embedded in the PEGASUS project (www.pegasusprojekt.de/en) that is investigating generally accepted quality criteria, tools and methods as well as scenarios and situations for the release of highly-automated driving functions. PEGASUS is funded by the Federal Ministry for Economic Affairs and Energy (BMWi). In the PEGASUS project it was decided to use OpenDRIVE (www.opendrive.org) as an open and mature XML-based file format for the topological and topographical description of road networks, which is vendor-independent, contains all features to model real road networks and is supported by commonly used simulation software. Therefore, OpenDRIVE is a natural choice to model virtual tracks for test cases. In combination with OpenSCENARIO (www.openscenario.org) for describing dynamic behavior of objects and participants these two formats build a solid foundation to model environments for virtual test cases. It is a proven approach to use domain-specific languages (DSL) to reduce complexity and increase efficiency for testing purposes [Deursen]. This is also the chosen way for the presented solution, as OpenDRIVE is powerful but also quite complex. Modelling efforts can be reduced significantly by the introduction of such an abstraction layer into the prototyping toolchain of OpenDRIVE. It has to be expected that first scenarios of highly automated driving will occur on highways [Bartels]. Consequently, this fact allows in a first stage to focus on modelling highways and their characteristics in a DSL. Highways are usually not built at will, but follow strict rules and guidelines. For example, in Germany the "Richtlinie für die Anlage von Autobahnen" (RAA, [RAA]) defines possible cross sections, allowed markings and combination of longitudinal courses and other properties of highways. With this domain-specific knowledge bundled in a DSL it should be possible to rapidly increase efficiency of modelling realistic virtual highways for test cases. Another approach uses tiles containing street sections and surrounding objects based on standardized edges such as applied in the ENABLE-S3 project (www.enable-s3.eu). These tiles can be easily and quickly combined by a user to create larger areas. Obviously, this approach drastically increases productivity of a user. But on the contrary, as tiles must be combinable, the content near the edges has quite strict limitations, which result in rather unnatural street courses of the created maps. For limited scenarios (e.g. parking decks) this approach can be still valid though. The presented background leads to the research question for this paper: Can a DSL be used to efficiently model variants of highways to create (adequately realistic tracks) to describe test cases? The methodology used for this examination covers the following steps based on an experimental approach. To investigate this question, first the needed elements of highways were identified and are used to create a first version of a DSL called SimplifiedRoad. As next step, a transformation engine for SimplifiedRoad into OpenDRIVE was created. With these foundations the approach to use a DSL for describing highways for test cases can be evaluated. Especially aspects of usability, efficiency and proper modelling are investigated. The next sections discuss the results of our work. As relevant content from the road construction guidelines several attributes for describing the appearance of the road as well as the road infrastructure "on top" were identified: number of lanes and their width, line markings, course, elevation, lateral profile, traffic signs and environmental objects. A fundamental design goal of SimplifiedRoad is to be as similar to OpenDRIVE as possible without applying the complexity of OpenDRIVE to SimplifiedRoad. Especially some optional enhancements are introduced in addition to OpenDRIVE: SimplifiedRoad allows mirroring roads with a simple attribute and furthermore pre-defined cross sections can be applied. With this additions simple road segments can be described already with very few lines. Furthermore, meaningful default values are used for all elements where possible. For example, default coordinates of street segments are generated at the end of previous segments. Environmental objects like guide posts, guard rails or noise barriers are typically used repeatedly and consist of several individual elements, what is simplified. An important feature is the possibility to allow parametrization of attributes in a SimplifiedRoad file. That is especially helpful to manage several variants of a track with slight differences (e.g. different street widths). Another feature to be implemented in the near future is the integration of highway entries and exits based on guidelines and a possibility of modification, too. The implementation of the transformation tool is straightforward from this background. With SimplifiedRoad first test track results show a reduction of required lines and characters to just 10 % of the generated OpenDRIVE. Especially parametrization of these files has the potential to boost productivity further. The final conclusion is that using a DSL to efficiently model highway sections for test cases is a good choice. It must be admitted, that a format like OpenDRIVE was likely never designed to be edited manually. Compared with a visual track editor using a DSL editor has different challenges for the user, but also using the visual editor is not always intuitive to model correct logic. Using a DSL does not replace classical scenario editors, but complements certain use case creation. It can be expected that in future DSLs will gain importance for creation of virtual tracks for test cases.