=Paper=
{{Paper
|id=Vol-3028/D2-06-ESAAMM_2021_paper_5
|storemode=property
|title=Towards a Domain-Specific Language for the Virtual Validation of Cloud-native Mobility Services
|pdfUrl=https://ceur-ws.org/Vol-3028/D2-06-ESAAMM_2021_paper_5.pdf
|volume=Vol-3028
|authors=Philipp Heisig,Christoph Flick
}}
==Towards a Domain-Specific Language for the Virtual Validation of Cloud-native Mobility Services==
https://ceur-ws.org/Vol-3028/D2-06-ESAAMM_2021_paper_5.pdf
Towards a Domain-Specific Language for the
Virtual Validation of Cloud-native Mobility Services
Philipp Heisig Christoph Flick
IDiAL Institute Dortmund University of Applied Sciences and Arts
Dortmund University of Applied Sciences and Arts Dortmund, Germany
Dortmund, Germany christoph.flick001@stud.fh-dortmund.de
philipp.heisig@fh-dortmund.de
Abstract—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, cloud-
While the availability of automotive big data provides the basis
for innovative and disruptive mobility services, processing vehicle 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.
of simulations, traffic simulation in combination with network
simulation is more and more used for a virtual proof-of- 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
a prototypical domain-specific language tailored to the formal
description of connected vehicle scenarios and the according according validation of in-vehicle functionality, cloud-native
generation of simulation environments. Therefore, we make use mobility services operate upon networks of vehicles and infras-
of 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
DSL so far only support the setup of minimal traffic scenarios,
it already helps to abstract complexity and ease the set-up of 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 environ-
mental conditions like changing connectivity.
I. I NTRODUCTION 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 simu-
Internet 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 vir-
amount 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 reproduc-
be 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 de-
However, connected vehicles operate in a safety-critical and scribed validation aspects for connected vehicle scenarios. Co-
time-sensitive environment with changing conditions. Unre- simulation refers to the coupling and composition of multiple
Copyright © 2021 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
simulators to simulate an overall system [3]. Setting up such via a DSL that is designed for describing connected
co-simulation environments is, however, a complex and time- vehicle scenarios, e. g. how many and what types of
consuming task that requires a lot of domain knowledge and vehicles should be simulated. In addition, the DSL
may prevent developers and software architects from focusing can be extended to capture non-functional requirements
on the actual service implementation. As stated by Ersal et towards cloud-native mobility services like scalability.
al. [4], more research is needed in usability and specification The resulting Scenario Model, i. e. a model that con-
validation/testing. Especially small and medium-sized enter- forms to the DSL’s metamodel, acts as input for a set
prises (SMEs), cities and municipalities, or service providers of Config Generators, which automatically generates
yet outside of the automotive domain, such as insurances, are configurations for each simulator used in the scenario.
potential candidates for realizing innovative and cross-domain Depending on the simulation tool and in which way
mobility services, but lack expertise in automotive testing and it can be configured, model-to-model or model-to-text
validation approaches. transformations can be applied for the generation pro-
To ease the set-up of virtual testing environments and thus cess.
enable the development of cloud-native mobility services, we 3) Co-simulation: While the configurations allow to set
propose a model-based scenario description via a domain- up each simulator independently, they still need to be
specific language (DSL). Therefore, we define a first prototype integrated into a co-simulation environment including
of a DSL in this paper that can be used to generate basic traffic a component that is responsible for orchestrating and
scenarios as foundation for a virtual testing environment. controlling the simulation flow of each simulator to
In addition, we evaluate the applicability of the DSL via enable interoperability among the simulators. For this
the use case of a restricted traffic zone service. To run the step, existing open-source co-simulation frameworks
simulation, we make use of the co-simulation framework like Eclipse MOSAIC or Eclipse OpenMCx3 are poten-
Eclipse MOSAIC1 along with the traffic simulator Eclipse tial candidates to be used. The simulation environment
SUMO2 and Eclipse MOSAIC’s Simple Network Simulator then generates large amount of semantically enriched
for simulating ad hoc communication. vehicle data on different levels of detail. For replication
The remainder of this paper is organized as follows: Sec- of tests or to carry out tests at any time, the generated
tion II introduces a general approach on how to enable virtual data will be persisted in a database.
testing of cloud-native mobility services. Afterward, Sec- 4) Feedback Loop: In the last step, test data from the
tion III proposes a first version of a DSL to formally describe simulation will be contentiously fed into the mobility
traffic scenarios along with a generator for SUMO simulator service to test both the service functionality and the
configurations. Section IV then evaluate the applicability of software architecture behind it. Predefined metrics as-
the DSL via the use case of a restricted traffic zone service, sess the architecture against the different non-functional
while Section V discusses the results and potential drawbacks. requirements defined in the Scenario Model, such as
Finally, Section VI concludes this work. response time or the number of vehicles that have been
simultaneously served. The test results are generated
II. V IRTUAL T ESTING C LOUD - NATIVE M OBILITY by a Report Generator, which helps the developer to
S ERVICES improve the service implementation and software archi-
This section introduces a model-based approach to ease the tecture behind it. By repeating the test, either via new
set-up of co-simulation environments for connected vehicle or based on the previous data sets, Feedback Loops can
scenarios. The overall goal is to provide sufficient simulation be established.
data for testing cloud-native mobility services by generating an
adequate simulation environment via a model-based scenario III. D OMAIN - SPECIFIC L ANGUAGE FOR C ONNECTED
description. As shown in Figure 1, the approach basically V EHICLE S CENARIOS
consists of four steps that are described in the following: While the previous section introduced the overall testing
1) Scenario Specification: The first step is the definition of approach for connected vehicle scenarios, this section aims at
a connected vehicle scenario including its requirements, realizing the second step of the approach (Modeling and Con-
which is usually done by a domain expert in natural figuration) by proposing a first draft of a DSL for generating
language. Based on this, software architects can start to multi-modal traffic scenarios.
define a first sketch of a software architecture and de- In general, DSLs are languages designed to describe and
velopers may implement basic functionality. Likely, the solve problems within a specific application domain. DSLs
architecture will be based on a microservice architecture helps domain expert to read, understand, and even write code
(MSA) to feature scalability and flexibility [5]. via formalized domain models that conform to the metamodel
2) Modeling and Configuration: Within the second step, of the corresponding DSL. In combination with code gen-
the informal Scenario Specification will be formalized erators, DSLs are powerful tools to abstract the underlying
complexity of software systems and enhance development
1 https://www.eclipse.org/mosaic/
2 https://www.eclipse.org/sumo/ 3 https://projects.eclipse.org/projects/automotive.openmcx
Fig. 1. Model-based testing approach for connected vehicle scenarios
efficiency. Thus, we propose the usage of a DSL to formally figuration values. In the case of SUMO, for example, the file
describe requirements for connected vehicle scenarios. generation feature of Eclipse Xtext is used to create a .sumocfg
However, connected vehicle scenarios are complex and file, which is the central configuration for a SUMO scenario.
involve a lot of varying and uncertain factors, e. g. different As the DSL is intended to rely on open standards and reuse
vehicles with different configurations are interacting among existing tools as much as possible, the road network generator
each other and with further traffic participants and infrastruc- netgenerate5 in combination with the randomTrips.py script
ture such as cyclists, pedestrians, traffic lights. This leads to is used to generate a road network as well as random traffic
a tremendous number of possible scenarios that need to be demand, respectively, in the form of XML files. In addition to
tested [6]. Therefore, we focus in this paper on the definition the DSL’s capabilities to configure the generation of network
of minimal traffic scenarios for a first proof of concept. The and traffic demand, it also allows to refer existing files
scope of the DSL is to provide a simple, straightforward way to alternatively, e. g. from real-world scenarios. Apart from the
setup a traffic simulator with scenarios and simulator settings. ability to describe network and traffic demand, the DSL offers
For the first prototype, our DSL will integrate a code gener- more configuration options for the simulation in general, e. g.
ator (Config Generator) for the open-source traffic simulation the user of the DSL can set the step length of the simulation
suite Eclipse SUMO, which is designed for microscopic simu- to influences its granularity.
lations and supports, among other things, large road networks Although traffic simulation provides already a meaningful
and the modeling of inter-modal traffic systems including set of vehicle data for testing, coupling at least a traffic
vehicles, public transport, and pedestrians. In addition, Eclipse simulator with a network simulator within a co-simulation
SUMO is well established in the research community and environment is necessary for simulating connected vehicle
provides real-world scenarios. For the implementation of the scenarios. Eclipse MOSAIC6 is an open-source, multi-domain,
DSL, Eclipse Xtext4 is used as it is also open-source and co-simulation framework for connected and automated mo-
provides quality-of-life features such as the editor support. bility that supports the integration and coupling of simu-
Listing 1 shows an excerpt of the Xtext grammar for the DSL, lators from different domains. To run a basic traffic sce-
while Table I depicts the different building block in detail. nario within Eclipse MOSAIC, a SUMO network file and
The foundation of the DSL is built by one or more a SUMO configuration file are required, whereas the route
configure blocks which contain the configuration details file is created by the MOSAIC SUMO Ambassador during
for a specific simulator, e. g. configure SUMO could be execution. While these files can be already generated with
used to start a configuration block for SUMO. For each the SUMO Config Generator of our DSL, running SUMO
configure block, and as such for each simulator, a separate within MOSAIC requires further files such as a runtime.json,
configuration file will be created based on predefined Config a mapping config.json for mapping simulated applications to
Generator. Therefore, the generator traverses the model and the simulation units, and a scenario database, which contains
converts the data from the DSL into simulator-specific con-
5 https://sumo.dlr.de/docs/netgenerate.html
4 https://www.eclipse.org/Xtext/ 6 https://www.eclipse.org/mosaic/
data about the roads, road connections, potential road restric- List:
list+=STRING (’,’ list+=STRING)*;
tions, and all possible routes which vehicles may take in the
simulation. To also automate the setup of these files and run enum Mode:
Simple | Docker | Docker_TraCI | MOSAIC | MOSAIC_Docker;
SUMO scenarios within Eclipse MOSAIC, one can use the
MOSAIC mode of our DSL, which generates the required files enum GeneratorType:
Grid | Spider | Random;
with default values. The mode also enables the simulation
of existing SUMO traffic scenarios with MOSAIC via the enum Alogrithm:
dijkstra | astar | CH | CHWrapper;
SumoScenarioAmbassador instead of using a scenario
database. Basically, the SumoScenarioAmbassador im- enum Simulator:
plements a TraCI7 client that sends all relevant commands to SUMO;
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 Table I
mode is active, not only the SUMO files are generated but D ESCRIPTION OF THE DIFFERENT DSL BUILDING BLOCKS
also a Dockerfile which contains the commands to create a Building Block Description
fully-functional image including the desired simulators and the
Mode The mode for the code generator. Possible values
setup for those generators. Besides, a README.md gets gen- are Simple, Docker, Docker_TraCI, MOSAIC, and
erated with instructions and commands to run the dockerized MOSAIC_Docker. When the code generator is executed
simulation suite. in Simple mode, the simulator configuration is gener-
ated without any extras. MOSAIC tells the code generator
Listing 1 to generate additional files to run SUMO scenarios in
E XCERPT OF THE DSL’ S X TEXT GRAMMAR the co-simulation environment MOSAIC. The Docker,
MOSAIC_Docker, and Docker_TraCI modes addition-
Domainmodel: ally generate a Dockerfile to run the simulation. The latter
(’mode’ mode=Mode)? will also generate a configuration which runs the SUMO
config+=Config+; simulator with a port open for TraCI.
Config: Config Includes the configuration properties for a specific simulator.
’configure’ name=Simulator ’{’ It has to be used exactly once for each simulator to be
(input=Input & configured.
output=Output? &
time=Time? & Input Provides the input data for the defined simulators in
routing=Routing?) Config. The input can be described either via a
’}’; GeneratorInput or a FileInput.
Input: Generator When GeneratorInput is provided, the code generator
’input’ ’{’ Input also generates road networks and traffic demand in addition
input=(FileInput | GeneratorInput) to the configuration. To achieve that, a GeneratorType
’}’;
and a size for the network need to be provided. Additionally,
GeneratorInput: a seed can be set for the random generator so the result can
’generate’ type=GeneratorType ’size’ size=INT; be regenerated.
(’random-seed’ randomSeed=INT)?;
Generator The type of road network that needs to be generated. The
FileInput: Type options here are (i) Grid to generate a network with a grid
{FileInput} layout; (ii) Spider to generate a network in form of a
((’netFile’ netFile=STRING) & spider’s web; or (iii) Random to generate a random network
(’routeFiles’ routeFiles=List)? & without a predefined layout.
(’additionalFiles’ additionalFiles=List)?);
FileInput Tells the code generator to use the configuration files
Output: provided in this block. The files that can be set here
{Output} ’output’ ’{’ are the (i) netFile that contains the description of the
((humanReadable?=’humanReadable’)? & network; (ii) one or more optionally routeFiles which
(’statisticFile’ statisticFile=STRING)? & describe the routes simulations entities may take; and (iii)
(’summaryFile’ summaryFile=STRING)? & additionalFiles as placeholder for various purposes.
(’tripinfoFile’ tripinfoFile=STRING)?)
’}’; Output Contains properties to define the output of the simulation.
For example, if and where statistics or a summary file should
Time:
be produced.
{Time} ’time’ ’{’
((’start_at’ start=INT ’seconds’)? & Time The Time block configures time-based properties. In partic-
(’end_at’ end=INT ’seconds’)? & ular, the start and end time of the simulation scenario, which
(’steplength’ steplength=DOUBLE ’seconds’)?)
control the overall running time, can be set. Furthermore,
’}’;
the duration of each simulation step can be influenced.
Routing: Routing The Routing block contains properties to influence the
{Routing} ’routing’ ’{’
((’algorithm’ algorithm=Alogrithm)?)
routing behavior of the simulation. The main setting here
’}’; is the routing algorithm to be used, which can be either
dijkstra, astar, CH, or CHWrapper [7].
7 https://sumo.dlr.de/docs/TraCI.html
IV. U SE C ASE : R ESTRICTED T RAFFIC Z ONE
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 commu-
nication. 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 Fig. 2. Visualization of the simulation for the restricted traffic zone use case
process the stop signal and execute it.
This use case involves different types of vehicles and
latitude and longitude values. The communication between
devices with software running on embedded devices as well as
the roadside unit and vehicles is based on IEEE 802.11p and
within the cloud. Developing such a service requires a through
can be simulated by using the Simple Network Simulator,
investigation and developers implementing the service have
which is already integrated in Eclipse MOSAIC and can be
to assess the functionality and software architecture behind
configured within the sns config.json file, e. g. the communi-
already at early stages of the development process. To save
cation range can be altered by setting the maximum allowed
time, money, and ensure high-quality services, a first proof
number of hops. For the implementation of the roadside
of concept via a simulated environment can give valuable
unit application, Eclipse MOSAIC integrates another interface,
feedback about the service quality and potential technical
called RoadSideUnitOperatingSystem, that provides
problems. Based on the DSL (see Listing 1), a rudimentary
functionality specific to roadside units, e. g. vehicle routing.
co-simulation environment for the use case can be defined as
The application creates a loop in which it broadcasts a message
shown in Listing 2, which basically creates a SUMO traffic
every few milliseconds to all vehicles inside the prior defined
scenario. Among the traffic simulation via Eclipse SUMO, also
geographical area using the GeoArea class.
the ad hoc close-range communication between vehicles and
Figure 2 shows the running simulation of the defined use
roadside unit as well as the in-vehicle application have to be
case, which is the third step of the process in Section II.
simulated. Thus, we make use of the co-simulation framework
During the simulation, vehicles were spawned on a highway
Eclipse MOSAIC and accordingly set the MOSAIC mode of
and then attempted to drive through the restricted area. In the
our DSL to further integrate the according simulators.
figure, simulation units sending messages are colored in red
Listing 2
E XAMPLE Scenario Model FOR THE RESTRICTED TRAFFIC ZONE USE CASE
while units receiving messages are colored green, i. e. vehicles
BASED ON THE DSL inside the area are receiving messages, and the roadside unit is
sending messages. Due to different vehicle speeds, the braking
mode MOSAIC
distance of each vehicles differs accordingly.
configure SUMO {
input { V. D ISCUSSION
netFile "highway.net.xml"
routeFiles "highway.rou.xml"
}
The use case in the previous section demonstrated that our
DSL prototype allows a highly expressive description of basic
time {
start_at 0 seconds
traffic scenario configurations by means of road networks as
end_at 1000 seconds 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
For the simulation of the in-vehicle application, a predefined MOSAIC. In addition, we support dockerized images for
Java class implementing the VehicleOperatingSystem greater portability. Generally, using a DSL improves produc-
interface is added in the generated mapping config.json file. tivity and reduces effort when creating traffic scenarios.
The application simply reduces the vehicle speed in case Nevertheless, there are several challenges and drawbacks
it receives a stop signal. Within the mapping config.json we observed when creating the DSL. One central issue when
file, also the location of the roadside unit can be set via creating a DSL for the description of traffic scenarios is the
complexity of the domain, especially when the goal of the DSL locally. Furthermore, more sophisticated end-to-end con-
language is the generation of concrete simulation scenarios. nected vehicle scenarios that integrate additional data sources,
The complexity of the DSL and its functionality have to be e. g. from traffic infrastructure or the smart city, are required to
carefully balanced so that it is powerful enough to describe extend our DSL with new building blocks. This also includes
traffic scenarios in a sufficient manner, but still be easily the support of additional simulators and automotive standards
graspable by domain experts and parsable by a code generator. such as the Vehicle Signal Specification8 . In addition to that,
If the DSL becomes too complex, it would lose most of its we want to define metrics to asses the architecture against non-
intended purpose. Essentially, the only remaining advantage functional requirements as described in step four in Section II.
would be the tool support that an DSL provides, such as auto Therefore, metrics specifically developed for MSAs can be
completion and syntax highlighting. integrated to identify, for example, microservices anti pattern
For a first prototype, our DSL was narrowed down to the [8] such as API versioning or hard-coded endpoints. Another
usage with the traffic simulator Eclipse SUMO. This focus example for a MSA-specific metric would be to measure the
led to a bias during the design of the DSL, resulting in the cyclic dependency, i. e. the amount of inter-service communi-
DSL’s structure to be similar to the structure of configuration cation.
files of SUMO scenarios. While this DSL was a first prototype
R EFERENCES
for a general proof-of-concept if formal description of traffic
scnearios in the context of connected vehicles are applicable, [1] Leandro D’Orazio, Filippo Visintainer, and Marco Darin. Sensor networks
on the car: State of the art and future challenges. In 2011 Design,
future versions of the DSL would need certain extensions to Automation & Test in Europe, pages 1–6. IEEE, 2011.
better describe general-purpose traffic scenarios. [2] Byron J Williams and Jeffrey C Carver. Characterizing software architec-
There are also some drawbacks when running a ture changes: A systematic review. Information and Software Technology,
52(1):31–51, 2010.
SUMO scenario within Eclipse MOSAIC via the [3] Cláudio Gomes, Casper Thule, David Broman, Peter Gorm Larsen, and
SumoScenarioAmbassador instead of having a proper Hans Vangheluwe. Co-simulation: State of the art. arXiv preprint
scenario database file: i) In-vehicle applications can only be arXiv:1702.00686, 2017.
[4] Tulga Ersal, Ilya Kolmanovsky, Neda Masoud, Necmiye Ozay, Jeffrey
mapped to vehicles types, but not individual vehicles; ii) all Scruggs, Ram Vasudevan, and Gábor Orosz. Connected and automated
simulated vehicles are spawned by SUMO which prevents road vehicles: state of the art and future challenges. Vehicle system
independent vehicle spawners; iii) simulated application are dynamics, 58(5):672–704, 2020.
[5] Tobias Schneider and A Wolfsmantel. Achieving cloud scalability with
not able to make use of the navigation module to influence microservices and devops in the connected car domain. In Software
vehicle’s routing in the applications; and iv) it is not possible Engineering (Workshops), pages 138–141, 2016.
to map applications to traffic lights. Another concern when [6] Sven Hallerbach. Simulation-based testing of cooperative and automated
vehicles. PhD thesis, Universität Oldenburg, 2020.
using the application simulator in Eclipse MOSAIC to test a [7] Pablo Alvarez Lopez, Michael Behrisch, Laura Bieker-Walz, Jakob Erd-
connected vehicle application is that it need to be wrapped mann, Yun-Pang Flötteröd, Robert Hilbrich, Leonhard Lücken, Johannes
with a MOSAIC application to be testable, which only work Rummel, Peter Wagner, and Evamarie Wießner. Microscopic traffic
simulation using sumo. In The 21st IEEE International Conference on
with Java applications currently. Intelligent Transportation Systems, pages 2575–2582. IEEE, November
2018.
VI. C ONCLUSION [8] Davide Taibi, Valentina Lenarduzzi, and Claus Pahl. Microservices anti-
patterns: A taxonomy. In Microservices, pages 111–128. Springer, 2020.
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 co-
simulation environment Eclipse MOSAIC via generators. De-
spite 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 sup-
port, the setup of simulation environments can be significant
simplified. Nevertheless, there are still several drawbacks as
discussed in Section V. Generally, a more generic, simulator-
independent approach is necessary that also integrates domain-
independent 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 8 https://genivi.github.io/vehicle signal specification/