Will OpenSCENARIO 2.0 support "Logically Abstract Scenarios"?
Will OpenSCENARIO 2.0 support "Logically Abstract Scenarios"? ... given this will eventually be logical and concrete for testing.
Definition:
"A scenario that mixes aspects of abstract scenarios and logical scenarios." (Accept IEEE and ASAM definitions of Abstract and Logical Scenarios.)
A scenario that:
- has every intention of being understood and tested by a machine
- uses an object oriented "structure for abstraction" 3) follows "rules of abstraction" 4) follows an intent to meet rules of concretion. Intentionally does not define all dimensions of test, so they can later be optimized. Missing from a Logically Abstract Scenario are both: a Parameter Space Full Factorial and method of selection.
Please see the purposed use case.
Use Case: As a scenario developer, I realize that there are aspects of the real world that are always expanding and changing (i.e. roads, maps, signs, road markings, types of objects and vehicles) and there are aspects of the world that don't seem to change as often like human behavior and weather. (As weather has existed for all human history and since the advent of cars on the roads and pedestrian behavior, we are doing the same sorts of things.) I want to create scenarios that are robust, long lasting and logical to human behaviors and parameters but are abstract to the aspects of the real world that are always changing. This is a partially logical scenario for position, speed and distance but abstract for specific map, location on map and for object representations. Some define this as a Logically Abstract Scenario. This allows for my robust scenario to always select from the latest library of aspects of real world. Weather can be tuned for individual test cases given a project ODD.
In our definition of a Logically Abstract Scenario, you must define an Abstract Road Network / Nexus that can logically be used to map onto a true RoadNetwork (OpenDrive file).
In our definition of a Logically Abstract Scenario, there is always a constraint for every parameter. Some of these constraint are under defined: keep(thisParameter == ""). This allows the user to later define: keep(thisParameter == [5..100]kph) ... keep(thisParmeter == 100).
This makes transitioning easy and possible: Abstract --> Logically Abstract --> Logical --> Concrete
This makes transitioning from "Logically Abstract" --> "Logical" as simple as assigning values to the constraints.
Process: Abstract (has no reference at all to a road network or lanes, has broken references that will require more work to map later) --> Logically Abstract (has constraints to satisfy a road network, lanes can be referenced abstractly, route can be referenced abstractly, I can create and anchor a starting distance from the beginning of a route or start of a RoadSegment / laneSection ) --> Logical ( values can easily just be assigned to exiting constraints (i.e. a list of RoadNetworks, list of direct lane and list of route assignment to constraints ) note: likely will need a dictionary for this --> Concrete (pick RoadNetwork, pick lane assignments, pick route) (Done.)
Please see my use case: http://www.plantuml.com/plantuml/uml/VLN1RYCt3BtxAuYzR084WoxQq-QoYqqE0P9DiMct5r_a6TgZHaDDHOqTz-jBKbOcJXC36KyaKUJZ8_dc2sUNyZI4XVspe9WHaj_q-JDyQdvjVci-G9V6HnmY-IIZz3X5aCSCLt03IHqmV-Ba7kNvGSJWjE7HsmpGrphfbd1BgRGmPBCjbY5dTipuDFegFEq0Nb1splQwEBCDzX0YgxZ2nZSAB_iDoGltPETz2Xciipx4IrKNFrjKPTadhRO-pOWdzlgNN26gu3g8dtCm8W3v5YGgBbOPYG8_X6XdmP76c65lTlwcCpv3ftwRq0esJdATZt99ZxpndFUAQucpXSGegGP7EUQUuWRtxeWjoM2XPhZi5cCBha1CyfoDHrON75EhhMOkJ_5_MlY9KPbMv3_qNi6-NCQ97iNmhu2cek_beJ7o3xxI1SWaR0pN9tdxAX5GrKHcVMI58zV-rQBg4ctJcz39DtGssPNYYTmnuICbCs86tY80qA7Qq_QPOfF8TugC8FujGPRqiC1PKr6pkEEpVkmFx0-fv9ZvO4neA9DSJ3AWiiebi6laajx9NBcrFXSKc6qWRzAuQ6rIa6U24iwdZg_zTta0fYprZ4oRFmMIHbEqRAzlxfg5elFLoMzYXzsFlSpY_9e-OVOOU3BnUTlVOoCGD5ANgYfGDuxljMHbZg_T_uZkkuxPidgiO4RueokWqdC7DbPfRbKBi5tV9eOpYf6yIpC7RavVoUKsJstH7277Tp4dsLU9ViGmEG8F3LIroCyCozsrrH2Rz_Awlp0t3mcq4PISq-vjB_d9QcZhlGHouMsDtHgFdZI4tDTvydKK7CEkCxM323ODcBUcLqTjDSqDKB0dunmXzbrBhkNrL09XVlr4QkEt-ZgkIVEaXLOiw1ggAYgfV3zTXzn7B0Eyfl4I1tDK99NeNsoaUIC8ukoctYQZ-EkFEdfmmT5Sqqy9IoqIy9f-BE65nRLQz3RfDVbUL11pxoBB2Un4SHKeJUobRJcKEVZlSgXfjfBmxdhIENQ-dZKiIuFbMSosUZEnlI2xXJgPFfXjiY8ZeCzZtGMDTF8oQF0vA5onBCWCrAKHebcypgc168RP6YhGiJGjj7toAVFtzEMR-DaEDfc7KY1TuPdxzOlzAMAcicUsaQJ1irdseoAyefcmS_JA6e_U_o5Ze7Vibg8S9uiDQrV6UglaLAcET-vX82NTl_dwfuuCXgOJJVZqXNFsv-NjVlZ3nx81JUM7LTo24EJkSO_vb4hOC2YSaE5AiWtwBwcrE9QTQk8iWMlwg-GNiZw_UTTCzvitdeumvscdqonA6ox8y3sK1KRvSBpd5SV47gfY7y1m00
Describe your Question or Problem
Will OpenSCENARIO 2.0 support "Logically Abstract Scenarios"? ... given this will eventually be logical and concrete for testing.
Problem: I need to have this methodology recognized to ensure enough sharing of this type of scenario is possible within industry. I see a problem / gap of transitioning directly from "Abstract Scenario" to "Logical Scenario"; it feels like a lot of effort is necessary to make this transition. I would like there to be more ease in making a scenarios logical and then concrete. This definition is also necessary for tool vendors that want to build a tool to develop, transition or aid scenario progression.
Describe your research
Working currently with multiple tool vendors on these topics. Have seen the expectations of vendors. OpenScenario 1.0 has these constraints, in concrete scenarios. Vendors are looking for faster ways to make this transition from 1.0 to 2.0 easier.
Proposal 1
Implement Logically Abstract Scenario Use Case in Work Flow folder: using the contents of : LogicallyAbstractScenarioUseCase_2021_Aug_07-fixed.zip
LogicallyAbstractScenarioUseCase_2021_Aug_07-fixed.zip
LogicallyAbstractScenarioUseCasePlant_UML.uml
Ask your question
Can the Usage and Pragmatics group consider this use case?