-Future vehicles can be considered as ”IoT devices on liable vehicle connectivity with changing data transfer rates wheels” as they exhibit high-performance computation resources, must be expected and real-time processing of the resulting various sensing devices, and a data-driven software architecture. data may be necessary for certain features. Furthermore, cloudfWorhiinlenothveataivveaialanbdilditiysruofptaivuetommoobtiilvietybsiegrvdiacteas, pprroovciedsessintghevebhaicslies native mobility services have to scale with the high number of data within the cloud poses also several challenges. A major vehicles on the road, while the architecture has to process also challenge in this context is the validation of cloud-native mobility a variance in data stemming from different types of vehicles. services regarding their proper functionality and the fulfillment Hence, scalable, resilient, and secured mobility services are of non-functional requirements. Due to the cost-efficient nature required to achieve the vision of connected vehicles. soifmsuimlautiloantioinss, mtroarfeficasnidmumlaotrioen uinsedco mfobrinaatiovnirtwuaitlh pnreotowfo-orfk- A major challenge here is to test and validate mobility concept of mobility services and their software architectures. services regarding their proper functionality and the fulfillment Nevertheless, the creation of adequate simulation environments of non-functional requirements, in particular scalability and specific to connected vehicle scenarios is time-consuming and reliability. While occasionally applied test approaches in the requires explicit domain knowledge. In this paper, we present automotive domain focused on the vehicle itself and the adepscrroitpottiyopnicoafl dcoonmnaeicnt-esdpevciefihciclleansgcueangaeritoasiloarnedd tthoe thaeccfoorrdminagl according validation of in-vehicle functionality, cloud-native generation of simulation environments. Therefore, we make use mobility services operate upon networks of vehicles and infrasof the traffic simulator Eclipse SUMO as well as the co-simulation tructure devices and thus require a massive amount of varying environment Eclipse MOSAIC and demonstrate the usage of our and vehicle-specific data that need to be fed into the services DSL via the use case of a restricted traffic zone. Although the for testing. As traffic scenarios are manifold and complex, test iDt SaLlresoadfyarhoelnplsy tsoupapbosrttratchte csoemtuppleoxfitmyiannimd aelatsreaftfihce ssceetn-uaprioosf, drives based on a vehicle fleet or setting up a large number of simulation environments for connected vehicle scenarios. hardware and vehicle nodes to generate vehicle-specific data Index Terms-Connected Vehicles, Simulation, Cloud Comput- are not feasible from an economic and operational perspective, ing, IoT, Domain-specific Language, Software Modeling whereas dummy data lack of semantics and neglect environmental conditions like changing connectivity. I. INTRODUCTION A promising way to still establish a testing process for Technological advances, digitization, and area-wide mobile cloud-native mobility services is the usage of traffic simuInternet have transformed vehicles into software-based high lations to generate context-specific automotive data that goes tech products with built-in connectivity and autonomous driv- beyond rudimentary or fake data-sets. In combination with ing features. These vehicles are characterized by the massive network simulators, connected vehicle scenarios can be viramount of multi-modal data emitted by hundreds of various tually created for a proof-of-concept design and evaluation. sensors [1] to provide context information about the vehicle Due to the cost-efficient nature of simulations, virtual testing itself and its environment, e. g. to detect road conditions, can be carried out through the whole development process and monitor tire pressure, or recognize driver's fatigue. Sharing feedback loops based on simulation data can be established to these data within the Internet of Things (IoT) by means test and improve services again and again. Such feedback is of connected vehicles facilitates vehicle data collection and especially valuable at early stages of a development process processing at scale in multiple and simultaneously operating as it provides crucial insights on potential problems with the services running in the cloud. By utilizing cloud computing defined software architecture or used technology and prevents capabilities for data fusion, analysis, and processing, innova- costly and complex late-lifecycle changes [2]. tive and data-driven mobility services running in the cloud can Nevertheless, simulators are usually specialized in reproducbe realized, spanning from road safety over smart, efficient, ing certain aspects, but at least traffic and network simulators and green transportation to location-dependent services. have to be interconnected to support all of the previously deHowever, connected vehicles operate in a safety-critical and scribed validation aspects for connected vehicle scenarios. Cotime-sensitive environment with changing conditions. Unre- simulation refers to the coupling and composition of multiple
simulators to simulate an overall system [
To ease the set-up of virtual testing environments and thus enable the development of cloud-native mobility services, we propose a model-based scenario description via a domainspecific language (DSL). Therefore, we define a first prototype of a DSL in this paper that can be used to generate basic traffic scenarios as foundation for a virtual testing environment. In addition, we evaluate the applicability of the DSL via the use case of a restricted traffic zone service. To run the simulation, we make use of the co-simulation framework Eclipse MOSAIC1 along with the traffic simulator Eclipse SUMO2 and Eclipse MOSAIC’s Simple Network Simulator for simulating ad hoc communication.
The remainder of this paper is organized as follows: Section II introduces a general approach on how to enable virtual testing of cloud-native mobility services. Afterward, Section III proposes a first version of a DSL to formally describe traffic scenarios along with a generator for SUMO simulator configurations. Section IV then evaluate the applicability of the DSL via the use case of a restricted traffic zone service, while Section V discusses the results and potential drawbacks. Finally, Section VI concludes this work.
II. VIRTUAL TESTING CLOUD-NATIVE MOBILITY
SERVICES
This section introduces a model-based approach to ease the
set-up of co-simulation environments for connected vehicle
scenarios. The overall goal is to provide sufficient simulation
data for testing cloud-native mobility services by generating an
adequate simulation environment via a model-based scenario
description. As shown in Figure 1, the approach basically
consists of four steps that are described in the following:
1) Scenario Specification: The first step is the definition of
a connected vehicle scenario including its requirements,
which is usually done by a domain expert in natural
language. Based on this, software architects can start to
define a first sketch of a software architecture and
developers may implement basic functionality. Likely, the
architecture will be based on a microservice architecture
(MSA) to feature scalability and flexibility [
III. DOMAIN-SPECIFIC LANGUAGE FOR CONNECTED
VEHICLE SCENARIOS
While the previous section introduced the overall testing approach for connected vehicle scenarios, this section aims at realizing the second step of the approach (Modeling and Configuration) by proposing a first draft of a DSL for generating multi-modal traffic scenarios.
In general, DSLs are languages designed to describe and solve problems within a specific application domain. DSLs helps domain expert to read, understand, and even write code via formalized domain models that conform to the metamodel of the corresponding DSL. In combination with code generators, DSLs are powerful tools to abstract the underlying complexity of software systems and enhance development
efficiency. Thus, we propose the usage of a DSL to formally describe requirements for connected vehicle scenarios.
However, connected vehicle scenarios are complex and
involve a lot of varying and uncertain factors, e. g. different
vehicles with different configurations are interacting among
each other and with further traffic participants and
infrastructure such as cyclists, pedestrians, traffic lights. This leads to
a tremendous number of possible scenarios that need to be
tested [
For the first prototype, our DSL will integrate a code generator (Config Generator) for the open-source traffic simulation suite Eclipse SUMO, which is designed for microscopic simulations and supports, among other things, large road networks and the modeling of inter-modal traffic systems including vehicles, public transport, and pedestrians. In addition, Eclipse SUMO is well established in the research community and provides real-world scenarios. For the implementation of the DSL, Eclipse Xtext4 is used as it is also open-source and provides quality-of-life features such as the editor support. Listing 1 shows an excerpt of the Xtext grammar for the DSL, while Table I depicts the different building block in detail.
The foundation of the DSL is built by one or more configure blocks which contain the configuration details for a specific simulator, e. g. configure SUMO could be used to start a configuration block for SUMO. For each configure block, and as such for each simulator, a separate configuration file will be created based on predefined Config Generator. Therefore, the generator traverses the model and converts the data from the DSL into simulator-specific con
figuration values. In the case of SUMO, for example, the file generation feature of Eclipse Xtext is used to create a .sumocfg file, which is the central configuration for a SUMO scenario. As the DSL is intended to rely on open standards and reuse existing tools as much as possible, the road network generator netgenerate5 in combination with the randomTrips.py script is used to generate a road network as well as random traffic demand, respectively, in the form of XML files. In addition to the DSL’s capabilities to configure the generation of network and traffic demand, it also allows to refer existing files alternatively, e. g. from real-world scenarios. Apart from the ability to describe network and traffic demand, the DSL offers more configuration options for the simulation in general, e. g. the user of the DSL can set the step length of the simulation to influences its granularity.
Although traffic simulation provides already a meaningful set of vehicle data for testing, coupling at least a traffic simulator with a network simulator within a co-simulation environment is necessary for simulating connected vehicle scenarios. Eclipse MOSAIC6 is an open-source, multi-domain, co-simulation framework for connected and automated mobility that supports the integration and coupling of simulators from different domains. To run a basic traffic scenario within Eclipse MOSAIC, a SUMO network file and a SUMO configuration file are required, whereas the route file is created by the MOSAIC SUMO Ambassador during execution. While these files can be already generated with the SUMO Config Generator of our DSL, running SUMO within MOSAIC requires further files such as a runtime.json, a mapping config.json for mapping simulated applications to the simulation units, and a scenario database, which contains
6https://www.eclipse.org/mosaic/ data about the roads, road connections, potential road restrictions, and all possible routes which vehicles may take in the simulation. To also automate the setup of these files and run SUMO scenarios within Eclipse MOSAIC, one can use the MOSAIC mode of our DSL, which generates the required files with default values. The mode also enables the simulation of existing SUMO traffic scenarios with MOSAIC via the SumoScenarioAmbassador instead of using a scenario database. Basically, the SumoScenarioAmbassador implements a TraCI7 client that sends all relevant commands to the running SUMO instance.
To further improve the portability of the simulation, a docker mode was introduced to the language, which can be enabled by putting mode Docker at the top of a file. When the docker mode is active, not only the SUMO files are generated but also a Dockerfile which contains the commands to create a fully-functional image including the desired simulators and the setup for those generators. Besides, a README.md gets generated with instructions and commands to run the dockerized simulation suite.
Listing 1
EXCERPT OF THE DSL’S XTEXT GRAMMAR Domainmodel: (’mode’ mode=Mode)? config+=Config+; Config: ’configure’ name=Simulator ’{’ (input=Input & output=Output? & time=Time? & routing=Routing?) ’}’; Input: ’input’ ’{’
input=(FileInput | GeneratorInput) ’}’; GeneratorInput: ’generate’ type=GeneratorType ’size’ size=INT; (’random-seed’ randomSeed=INT)?; FileInput: {FileInput} ((’netFile’ netFile=STRING) & (’routeFiles’ routeFiles=List)? & (’additionalFiles’ additionalFiles=List)?); Output: {Output} ’output’ ’{’ ((humanReadable?=’humanReadable’)? & (’statisticFile’ statisticFile=STRING)? & (’summaryFile’ summaryFile=STRING)? & (’tripinfoFile’ tripinfoFile=STRING)?) ’}’; Time: {Time} ’time’ ’{’ ((’start_at’ start=INT ’seconds’)? & (’end_at’ end=INT ’seconds’)? & (’steplength’ steplength=DOUBLE ’seconds’)?) ’}’; Routing: {Routing} ’routing’ ’{’
((’algorithm’ algorithm=Alogrithm)?) ’}’;
Config Input Generator Input Generator Type FileInput Output Time Routing List:
list+=STRING (’,’ list+=STRING)*; enum Mode:
Simple | Docker | Docker_TraCI | MOSAIC | MOSAIC_Docker; enum GeneratorType:
Grid | Spider | Random; enum Alogrithm:
dijkstra | astar | CH | CHWrapper; enum Simulator:
SUMO;
This section introduces the use case of a restricted traffic zone to demonstrate and evaluate the DSL prototype defined in Section III. In this use case, unauthorized vehicles are prevented from entering a predefined area for safety reasons, e. g. when a festival is taking place. Therefore, a roadside unit is placed near or inside the restricted zone that communicates with all vehicles close by via ad hoc close-range communication. The roadside unit request the vehicle type and ID from each vehicle, calculates the distance of the vehicle to the restricted traffic zone, and send all data to a cloud-native service deployed by the city’s traffic department. The service receives the data and checks if the vehicle is allowed to enter the zone, e. g. vehicles like an ambulances should be allowed to enter the zone. If the vehicle is not authorized and violates the rules by approaching too close to the restricted traffic zone, the service broadcasts a stop signal via the roadside unit to the vehicle, which has an in-vehicle application deployed that can process the stop signal and execute it.
This use case involves different types of vehicles and devices with software running on embedded devices as well as within the cloud. Developing such a service requires a through investigation and developers implementing the service have to assess the functionality and software architecture behind already at early stages of the development process. To save time, money, and ensure high-quality services, a first proof of concept via a simulated environment can give valuable feedback about the service quality and potential technical problems. Based on the DSL (see Listing 1), a rudimentary co-simulation environment for the use case can be defined as shown in Listing 2, which basically creates a SUMO traffic scenario. Among the traffic simulation via Eclipse SUMO, also the ad hoc close-range communication between vehicles and roadside unit as well as the in-vehicle application have to be simulated. Thus, we make use of the co-simulation framework Eclipse MOSAIC and accordingly set the MOSAIC mode of our DSL to further integrate the according simulators.
Listing 2 EXAMPLE Scenario Model FOR THE RESTRICTED TRAFFIC ZONE USE CASE
BASED ON THE DSL mode MOSAIC configure SUMO { input { netFile "highway.net.xml" routeFiles "highway.rou.xml" } time { start_at 0 seconds end_at 1000 seconds } }
For the simulation of the in-vehicle application, a predefined Java class implementing the VehicleOperatingSystem interface is added in the generated mapping config.json file. The application simply reduces the vehicle speed in case it receives a stop signal. Within the mapping config.json file, also the location of the roadside unit can be set via latitude and longitude values. The communication between the roadside unit and vehicles is based on IEEE 802.11p and can be simulated by using the Simple Network Simulator, which is already integrated in Eclipse MOSAIC and can be configured within the sns config.json file, e. g. the communication range can be altered by setting the maximum allowed number of hops. For the implementation of the roadside unit application, Eclipse MOSAIC integrates another interface, called RoadSideUnitOperatingSystem, that provides functionality specific to roadside units, e. g. vehicle routing. The application creates a loop in which it broadcasts a message every few milliseconds to all vehicles inside the prior defined geographical area using the GeoArea class.
Figure 2 shows the running simulation of the defined use case, which is the third step of the process in Section II. During the simulation, vehicles were spawned on a highway and then attempted to drive through the restricted area. In the figure, simulation units sending messages are colored in red while units receiving messages are colored green, i. e. vehicles inside the area are receiving messages, and the roadside unit is sending messages. Due to different vehicle speeds, the braking distance of each vehicles differs accordingly.
The use case in the previous section demonstrated that our DSL prototype allows a highly expressive description of basic traffic scenario configurations by means of road networks as well as traffic demand. By using the code generation facilities of Eclipse Xtext, SUMO simulation scenarios can be generated and also integrated in the co-simulation environment Eclipse MOSAIC. In addition, we support dockerized images for greater portability. Generally, using a DSL improves productivity and reduces effort when creating traffic scenarios.
Nevertheless, there are several challenges and drawbacks we observed when creating the DSL. One central issue when creating a DSL for the description of traffic scenarios is the complexity of the domain, especially when the goal of the language is the generation of concrete simulation scenarios. The complexity of the DSL and its functionality have to be carefully balanced so that it is powerful enough to describe traffic scenarios in a sufficient manner, but still be easily graspable by domain experts and parsable by a code generator. If the DSL becomes too complex, it would lose most of its intended purpose. Essentially, the only remaining advantage would be the tool support that an DSL provides, such as auto completion and syntax highlighting.
For a first prototype, our DSL was narrowed down to the usage with the traffic simulator Eclipse SUMO. This focus led to a bias during the design of the DSL, resulting in the DSL’s structure to be similar to the structure of configuration files of SUMO scenarios. While this DSL was a first prototype for a general proof-of-concept if formal description of traffic scnearios in the context of connected vehicles are applicable, future versions of the DSL would need certain extensions to better describe general-purpose traffic scenarios.
There are also some drawbacks when running a SUMO scenario within Eclipse MOSAIC via the SumoScenarioAmbassador instead of having a proper scenario database file: i) In-vehicle applications can only be mapped to vehicles types, but not individual vehicles; ii) all simulated vehicles are spawned by SUMO which prevents independent vehicle spawners; iii) simulated application are not able to make use of the navigation module to influence vehicle’s routing in the applications; and iv) it is not possible to map applications to traffic lights. Another concern when using the application simulator in Eclipse MOSAIC to test a connected vehicle application is that it need to be wrapped with a MOSAIC application to be testable, which only work with Java applications currently.
In this paper, we presented a first prototype for a DSL that supports the formal description of connected vehicle scenarios and the automatic derivation of a simulation environment for the traffic simulator Eclipse SUMO as well as the cosimulation environment Eclipse MOSAIC via generators. Despite that the DSL so far only support the setup of minimal traffic scenarios, we have shown with the use case of a restricted traffic zone that it is already possible to test more sophisticated connected vehicles applications that require the coupling of different simulators. By providing Docker support, the setup of simulation environments can be significant simplified. Nevertheless, there are still several drawbacks as discussed in Section V. Generally, a more generic, simulatorindependent approach is necessary that also integrates domainindependent testing aspects like data privacy. Therefore, a stronger focus should be placed on the integration of available open-source formats as the DSL foundation, such as ASAM OpenCRG, OpenDRIVE, and OpenSCENARIO
For the future we are planing to redesign our DSL regarding
more flexibility and provide a ready to use web-based user
interface without the hassle of installing and configuring the
DSL locally. Furthermore, more sophisticated end-to-end
connected vehicle scenarios that integrate additional data sources,
e. g. from traffic infrastructure or the smart city, are required to
extend our DSL with new building blocks. This also includes
the support of additional simulators and automotive standards
such as the Vehicle Signal Specification8. In addition to that,
we want to define metrics to asses the architecture against
nonfunctional requirements as described in step four in Section II.
Therefore, metrics specifically developed for MSAs can be
integrated to identify, for example, microservices anti pattern
[