Use cases list for the development of opGUI
Use Cases for the development of opGUI
The following list of use cases has been defined in order to drive the development of opGUI.
Use Case Nr | Title | Prerequisites (what should the user bring by his own and is not supported by the GUI for this specific use case?) | Short Description | Outcome | priority (A=high,B=middle,C=low) | Comment |
---|---|---|---|---|---|---|
This use case has been discarded, since it can be considered as a special case of Use Case 2 | ||||||
2 | Simulate a single or multiple basis scenarios | Simulation input data for one or several cases (ProfilesCatalog, SystemConfig, xosc/xodr ….) locally stored in individual config folders | The user sets up the LogLevel. For each case, the user sets up the path to the configs and results folders. The user sets up the path to the log file. The GUI checks if all input data exist. The user selects the simulations to be run, and triggers the simulation(s) (local /on a remote server/ on supercomputer/ in cloud). The GUI generates a config XML file opSimulationManager.xml. The GUI uses opSimulationManager.exe to run the simulation(s) (even for a single simulation). The user can load a config XML file opSimulationManager.xml and the GUI sets up the simulations accordingly. | simulation output (csv/xml defined by the user) for each case, and summarized output over all cases | A | Done |
3a | Configure single or multiple PCM simulation | PCM-database in SQLite format, SystemConfig locally stored | The user sets up the path to the PCM-Database. The GUI shows the list of cases stored in the PCM database. The user selects the cases to be simulated. The user defines the SystemConfig files which should be applied to the agents. The GUI converts the selected cases into input data for openPASS(ProfilesCatalog, xosc/xodr…) stored in individual config folders (one config folder for each case). The GUI exports a config XML file opSimulationManager.xml | converted input data for openPASS xodr/xosc/xml files in individual configs folders (one config folder for each case) | A | Done |
3b | Run single or multiple PCM simulations | converted input data for openPASS xodr/xosc/xml files in individual configs folders (one config folder for each case) | the simulations are run in the same way as in the Use Case 2 | simulation output (csv/xml defined by the user) in individual results folders | A | Done |
4 | Visually configure SystemConfig.xml | components XML locally stored | The user sets up the path to the folder in which the components xml are stored. The GUI graphically displays the components as function of their categories. The user defines by drag and drop a complete system constituted of one or several components. The user sets up the connections between components. The GUI checks if DLL libraries exist for the chosen components. The user can modify the components parameters, and the variables priority, offset, cycles and response. The user exports and saves the system xml file. The user can load an existing system. | SystemConfig.xml for further simulation runs | A | Done |
5 | Setup openPASS configuration files | Simulation input data (xosc/xodr), VehiclesCatalog and PedestrianCatalog locally stored | The user sets up (from scratch) the files ProfilesCatalog and SimulationConfig. The user exports the XML files. | checked XML files | A | |
This use case has been discarded: an expert who develops his own component is expected to deliver the corresponding XML file | ||||||
7 | Display and report the simulations status | The GUI provides the individual simulations status (scheduled, running, aborted, successful, failed). The GUI reports the global progress of the simulations (how many cases are scheduled, running, aborted, successful, failed). The GUI displays the individual log output in the GUI. | push up window with error.log file and link to it (maybe hint how to solve) | A | ||
8a | Visualize cyclics of the simulation results | successful simulation results | The user selects the simulations which should be post-processed . The GUI generates post-processing plots based on the cyclics results for one or several simulations (e.g. agents trajectories, agents velocities...) | specific plots | C | |
8b | Visualize statistics of the simulation results | successful simulation results | The user selects the simulations which should be statistically analysed. The GUI computes the statistics, displays the results and generates post-processing plots | specific statistic values and plots | C | |
8c | Visualize plots of the simulation results | successful simulation results | The user selects the simulations which should be analysed. The GUI generates post-processing plots based on the results found in the XML output files | specific plots | C | |
9 | Use an E2E test as basis for own simulations | End-to-end tests and Common folder locally stored | The user chooses an E2E test from dropdown/tree view. The user gives the path where the new configs should be stored. The content of the Common folder is copied into the chosen location. The content of the chosen E2E is copied into the chosen location (overwrites the existing data copied from Common). The user can set up the files ProfilesCatalog and SimulationConfig. | configs folder with valid input data | A | |
10 | Vizualize and edit Systemconfig Blueprint | systemConfigBlueprint.xml locally stored | The user can load the systemConfigBlueprint.xml in the system editor (Use Case 4) and visualize its content (graphically or in form of table, or any suitable form). The user can modify the components parameters, and the variables priority, offset, cycles and response. The user can add new components and set up its parameters. The user can set up the connections between components. The GUI checks if the systemConfigBlueprint.xml is valid. | valid systemConfigBlueprint.xml | A | |
11 | Visualize simulation results in opVisualizer | sucessful simulation results, installed opVisualizer | For a given successful simulation, the user opens the opVisualizer from the GUI and visualizes the results (3D animation) | Visualization | B | |
12 | Integration of an external scenery visualizer | External scenery visualizer, openDRIVE file | The GUI integrates an external scenery visualizer. The user can call the external scenery visualizer from the GUI in order to visualize the content of a given openDRIVE file. The external Scenery visualizer could be opVisualizer. | visualized *xodr files | C | |
13 | Integration of an external scenery editor | External scenery editor, openDRIVE file, openSCENARIO file | The GUI integrates an external scenery editor. The user can call the external scenery editor from the GUI in order to modify the content of a given set of openDRIVE and openSCENARIO file. | edited *xodr/xosc files | C | |
14 | Usage of Sensor Positioner (within opVisualizer) | installed opVisualizer, files VehicleModelsCatalog and ProfilesCatalog locally stored | From the GUI, the user loads the vehicle geometry in opVisualizer. The user defines in opVisualizer the sensors position, direction and parameters (e.g. range, field of view). The user exports the necessary information in VehicleModelsCatalog or ProfilesCatalog | valid VehicleModelsCatalog.xosc/ProfilesCatalog.xosc | C | |
15 | Check validity of config set | a full set of simulation configs placed on hard drive | As a user I want to select a set of configs from the harddrive and get feedback from the Gui if this configs are complete and valid. The checks should contain schema checks and additional make sure all references can be resolved. | Result of the check (yes / no) and overview of the failed checks | B | |
16 | Deploy GUI on server | Cloud hosting platform | As a PO, I want to host the GUI on a server to make it accessible within the whole network. This could be achieved e.g. by containerization | GUI can be easily made available on a container platform | B | |
17 | Identity and Access Management (IAM) | As a PO, I want to restrict access to the data in the GUI (e.g. each user can only see his/her own simulations and configurations) | Users need to log in. Users see only own configurations/experiments | C | ||
18 | Visually configure several SystemConfig.xml | components XML locally stored | As a user, I want to visually set up several SystemConfig.xml | SystemConfig.xml for further simulation runs | C | done |
19 | Advanced assignment of systems in sets of simulations | As as user, and for a given set of simulations, I want to individually assign the system configuration applied to each simulated agent (e.g. by means of a table) | Converted SystemConfig.xml | C |
"Non" Use Cases
A list of "non use cases" has also been defined, which summarizes the features that are not expected to be implemented in the GUI:
Use Case Nr | Title | Short Description | Comment / Status |
---|---|---|---|
1 | odr/osc editing | We don't want to develop a openDRIVE or openSCENARIO Editor |
Edited by Gwendal Lucas