share
Required Metadata
Current code version
| Nr. | Code metadata description | Please fill in this column |
|---|---|---|
| C1 | Current code version | v1 |
| C2 | Permanent link to code/repository used for this code version | https://github.com/ftgTUGraz/DriverModel_Framework |
| C3 | Code Ocean compute capsule | none |
| C4 | Legal Code License | GPL-3.0 License |
| C5 | Code versioning system used | git |
| C6 | Software code languages, tools, and services used | C++, IPG CarMaker, PTV Vissim |
| C7 | Compilation requirements, operating environments & dependencies | Visual Studio |
| C9 | Support email for questions |
demin.nalic@tugraz.at
pandurevic@tugraz.at |
1 Motivation and significance
TFSS in virtual testing of automated driving systems is already standard procedure in automotive engineering. TFSS is mostly used in combination with other software tools for vehicle testing and simulation. Therefore, there are different co-simulation platforms for testing ADS in complex traffic environments as presented in hallerbach -nalic2019framework . All of these platforms have one point in common, the vehicle under test (VUT) is developed separately in a certain vehicle software tool (VST) and the traffic is externally imported by TFSS. Using these co-simulation platforms, the performance of developed ADS in complex traffic environment can be analyzed and approved. One very common use of TFSS is the impact analysis of ADS. For that, the TFSS should offer the possibility to manipulate and edit driver models to implement ADF in certain number of the vehicles and analyze the impact of ADS on traffic; see impact1 and impact2 . The focus of this research is to test ADS within a comprehensive traffic setting using TFSS. For this research, the co-simulation between IPG CarMaker and PTV Vissim trafficFlow was used for testing ADS; see the developed co-simulation framework based on co-simulation in nalic2019framework and cosimFramework . In this co-simulation framework, the VUT, the road network and the visualization are handled by IPG CarMaker and the traffic modelled and imported from PTV Vissim. The purpose of the co-simulation framework was to detect critical scenarios for the assessment of ADS. The definition of scenarios and critical scenarios in relation with automated driving can be found in following research papers; see scenario1 -scenario2 . In general, scenarios for testing of ADS represent special or relevant maneuvers which should be tested to approve the safety performance of ADS. As all TFSS are used in the field of traffic planning and modelling for general traffic analyses, the manipulation of traffic participants for testing of ADS was not considered in the past. Due to that, the cars do not collide with each other and do unpredictable movements which could lead to a critical maneuver. PTV Vissim provides the possibility to manipulate them via an external driver model DLL (Dynamic-Link Library) interface and offers a C++ code to generate external driver models which follow a defined and developed behavior, see vissim . The C++ code of PTV Vissim is edited and adjusted in a DMF to make the implementations of external driver models easier and more adaptive. For testing purposes of ADS, the Driver Model Framework (DMF) is developed to generate more critical scenarios in the co-simulation framework from nalic2019framework and use the detected scenarios for assessment of ADS. Additionally, the developed DMF offers other usage and provides the user with the possibility to easily implement a defined vehicle behavior, automated driving functions or any other functions which are relevant for traffic modelling and analysis. By implementing the stress-testing method presented in stm in the DMF, an increase of detected and relevant scenarios for testing ADS was achieved. For further research, the DMF will be used to adjust and improve the existing testing procedure and also for traffic analyses.
2 Software description
The external driver model, DLL interface provided by PTV Vissim, contains 3 essential functions from Vissim interface : DriverModelSetValue, DriverModelGetValue and DriverModelExecuteCommand. In DMF, these functions must be available and are an essential part of it. The Vissim participants, which are controlled by the DLL, are called DLL driver models (DDM) in further description. The DriverModelExecuteCommand value is passed upon each simulation step, denoting the action to be taken, such as initialization, driver creation, driver deletion and driver movement of each traffic participant controlled by the DLL in the TFSS. In between the commands, multiple calls for DriverModelSetValue and DriverModelGetValue are made for each vehicle controlled by the DLL driver model. The function DriverModelSetValue provides the DLL with the current vehicle values which can be stored, processed and modified. In order to provide Vissim with new values which will be used for the vehicle movement, multiple calls for DriverModelGetValue for each traffic participant are necessary. For the manipulation procedure, one vehicle in Vissim is set to be the VUT. In further text the vehicle will be referred to as EGO vehicle. This vehicle has a certain ID which can be freely defined and set. For the DMF, the area of interest is the surrounding area of the EGO vehicle which consists of other traffic participants, referred to as nearby vehicles in this paper.
Each Vissim call to the set or get method passes multiple arguments, one of which always denotes the value which is going to be set or achieved. After set is executed for each value of the vehicle, multiple set calls follow with the values of the nearby vehicles. Thus, information about ego vehicle and detected nearby vehicles is obtained and can be processed and prepared if needed. The whole set and get routine is performed for each vehicle controlled by the DMF for each simulation step. To collect the data of the surrounding area of the ego vehicle in order to manipulate it, the DMF builds a wrapper around it for handling the data by the user. The DMF provides the user with the basic methods necessary to read and manipulate the traffic participants relevant for the tested ego vehicle. The user has to implement two framework methods capture and action in order to create usable DLL.
In the action method, user shall define an action which will be applied to the target vehicles. One such action can be a braking maneuver of a traffic participant which is directly in front of the ego vehicle or a cut-in of the traffic participant in front of the ego vehicle. A systematic way to manipulate traffic participants using the DMF is presented in stm . The maneuvers are executed during the predefined time window and they are not scheduled for execution until the conditions in capture are met again and new action round is started.
The obvious advantage of the framework is that user does not care about keeping all nearby vehicles, taking care of vehicle IDs or if the nearby vehicles has up to date values. In the capture method, it is guaranteed that nearby vehicles which user can observe have up to date values and those selected as target vehicles are consistently being updated during the action time window.
2.1 Software Architecture
The driver model DLL framework is written in C++ and requires user to do so. It encapsulates the inner workings and provides the user with the simple interface. The class hierarchy can be seen in Fig. 1.
The InjectorAbstract class comprises most of the DMF logic including get and set methods which are called from the Vissim. They are required to be a part of InjectorAbstract since the whole DMF logic depends on them, reading out the data, storing it, scheduling the execution of capture and action methods and passing new data to Vissim. The Injector class is a child class of the InjectorClass which implements pure virtual methods capture and action. This inheritance serves the purpose of keeping users away from the inner workings of the framework and providing them with simple means of vehicle manipulation. Through this, the user code is separated from the DMF logic and it is simple for the user to write and organize. Besides that, user is free to extend the functionality of NearbyVehicle and EgoVehicle classes which keep the data of respective vehicle categories.
2.2 Software Functionalities
As mentioned in the software description, the user has to fill the code for the capture and action methods. The methods provided by the DMF upon which user depends are:
-
getAllNearbyVehicles
-
getVehiclesDownstream
-
getVehiclesUpstream
-
getCurrentSimTime
First three methods return a vector containing nearby vehicles, either all of them, or only vehicles in front or vehicles in behind of our ego vehicle. Each vehicle is represented by the
NearbyVehicle object which contains all relevant information about the vehicle, such as relative distance and speed to the ego vehicle, acceleration, relative position, etc.. These methods are meant to be used in capture method where the user is observing the traffic and labeling relevant vehicles as target vehicles. When the user-defined criteria is fulfilled, startAction method is to be called with specified action duration time and optionally selected pause time after action end. During the action window, user is taking the control over the target vehicles and after action time expires, internal model takes over the target vehicles. Through these methods, DMF provides user with these main functionalities:-
Providing the user with the up to date list of nearby vehicles
-
Letting the user to select target vehicles and manipulate them
-
Keeping the list of target vehicles updated during the action
-
Scheduling the capture and action methods in time
-
Taking and releasing the control of the vehicles from and to the user
Another important feature of the DMF is the two separate modes of operation. In both of them previously defined functionalities are present, but they require different approach and implementation for different modes of operation. The DMF can operate both in Vissim only and in co-simulation between CarMaker and Vissim.
3 Impact
-
The presented DMF provides the possibility to manipulate traffic participants in the TFSS of Vissim. By implementing automated driving functions using the DLL an impact analysis of these functions on traffic can be analyzed and evaluated.
-
The possibility to manipulate a certain traffic participant in the surrounding area of a vehicle under test can be used to provoke critical scenarios. Assuming that the vehicle under test is equipped with ADF, the provoked critical scenarios can be used to detect, assess and verify the ADS implemented in the vehicle under test.
-
The increase of relevant scenarios for testing automated can be achieved; see stm .
-
Using the DMF additional test procedures for testing stability or testing platooning systems can and will be defined and implemented for future works.
4 Conclusions
With the presented software framework, the user has the possibility to easily implement and adjust driver models for traffic participants using the traffic flow simulation software Vissim. That makes it possible to analyze traffic behavior of implemented models or to manipulate traffic participants for testing procedures of automated driving systems. Using the co-simulation between Vissim and IPG CarMaker with the adjustment of the presented framework, it was possible to upgrade the benefit of co-simulation for testing of automated driving systems.
5 Conflict of Interest
No conflict of interest exists: We wish to confirm that there are no known conflicts of interest associated with this publication and there has been no significant financial support for this work that could have influenced its outcome.
References
- (1) Hallerbach, Sven & Xia, Yiqun & Eberle, Ulrich & Köster, Frank. (2018). SAE Int. Journal of Connected and Automated Vehicles, ”Simulation-Based Identification of Critical Scenarios for Cooperative and Automated Vehicles”, doi:10.4271/2018-01-1066.. 1. 93-106.
- (2) Bansal, Prateek. ”Matlab-Vissim Interface for online optimization of Green Time splits.” ArXiv abs/2007.15208 (2020).
- (3) Schiller, A. (2019). Multi-resolution Traffic Simulation for Large-Scale High-Fidelity Evaluation of VANET Applications. In Simulating Urban Traffic Scenarios (pp. 17–36). Springer International Publishing.
- (4) Semrau, M. and Erdmann, J., Simulation Framework for Testing ADAS in Chinese Traffic Situations. In Proceedings of the 2016 SUMO User Conference, Berlin, Germany, 23–25 May 2016; pp. 103–115.
- (5) Barthauer, Mirko and A. Hafner. “Coupling traffic and driving simulation: Taking advantage of SUMO and SILAB together.” (2018).
- (6) D. Nalic, A. Eichberger, G. Hanzl, M. Fellendorf and B. Rogic, ”Development of a Co-Simulation Framework for Systematic Generation of Scenarios for Testing and Validation of Automated Driving Systems*,” 2019 IEEE Intelligent Transportation Systems Conference (ITSC), Auckland, New Zealand, 2019, pp. 1895-1901, doi: 10.1109/ITSC.2019.8916839.
- (7) Jaume Barceló (ed.), 2010. ”Fundamentals of Traffic Simulation,” International Series in Operations Research and Management Science, Springer, number 978-1-4419-6142-6.
- (8) Haberl, M., Fellendorf, M., Neuhold, R., Rudigier, M., Kerschbaumer, A., Eichberger, A., & Rogic, B. (2017). Simulation assisted impact analyses of automated driving on motorways for different levels of automation and penetration. Paper presented at mobil.TUM 2017, München, Germany.
- (9) L. Ye, T. Yamamoto and T. Morikawa, ”Heterogeneous Traffic Flow Dynamics under Various Penetration Rates of Connected and Autonomous Vehicle,” 2018 21st International Conference on Intelligent Transportation Systems (ITSC), Maui, HI, 2018, pp. 555-559, doi: 10.1109/ITSC.2018.8569975.
- (10) S. Ulbrich, T. Menzel, A. Reschka, F. Schuldt and M. Maurer, ”Defining and Substantiating the Terms Scene, Situation, and Scenario for Automated Driving,” 2015 IEEE 18th International Conference on Intelligent Transportation Systems, Las Palmas, 2015, pp. 982-988, doi: 10.1109/ITSC.2015.164.
- (11) Mugur, T., ”Enhancing ADAS Test and Validation with Automated Search for Critical Situations”, presented at DSC 2015, Berlin, September 16-18, 2015.
- (12) P. Junietz, F. Bonakdar, B. Klamann, and H. Winner, ”Criticality Metric for the Safety Validation of Automated Driving using Model Predictive Trajectory Optimization”, in IEEE Conference on Intelligent Transportation Systems, Proceedings, ITSC, vol. 2018-Novem, pp. 60–65, 2018
- (13) Fellendorf, M & Vortisch, P 2010, Microscopic Traffc Flow Simulator VISSIM. in Fundamentals of Traffic Simulation. 1 edn, vol. 145, International Series in Operations Research & Management Science, Springer Science+Business Media, New York, pp. 63-94.
- (14) Demin Nalic, Hexuan Li, Arno Eichberger, Christoph Wellershaus, Aleksa Pandurevic, & Branko Rogic. (2020). Stress Testing Method for Scenario Based Testing of Automated Driving Systems.
- (15) Nalic, D.; Pandurevic, A.; Eichberger, A.; Rogic, B. Design and Implementation of a Co-Simulation Framework for Testing of Automated Driving Systems. Preprints 2020, 2020110252 doi:10.20944/preprints202011.0252.v1.
-
(16)
IPG Automotive GmbH, [online] Available:
https://ipg-automotive.com/products-services/simulationsoftware/carmaker/