Simulation issueshttps://code.asam.net/groups/simulation/-/issues2022-04-11T13:44:41Zhttps://code.asam.net/simulation/openscenario/2.x/-/issues/93Will OpenSCENARIO 2.0 support "Logically Abstract Scenarios"?2022-04-11T13:44:41ZRichard HeidtmanWill 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 a...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:
1) has every intention of being understood and tested by a machine
2) 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.
<!--- Provide a general summary of the issue in the Title above -->
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](/uploads/3d1f4e254b3674fcf50f08a3100fad2d/LogicallyAbstractScenarioUseCase_2021_Aug_07-fixed.zip)
Updated UML:
'http://www.plantuml.com/plantuml/uml/dLPDR-Cs4xxxLmnyMHlmwdtJzkIzR93a420VHTBTNdePIsEB3KMg7CgE--ixGrgcrzraWGAHP9BpySmp7yndZXZYqDb9-Z5nFX84isdZ4YwgdwjVgel_moK30jVaC1WF3Mt9-fx20cuX45hpDq5iCSgB0W7gmptLaS6lTJD9mSu7sy0VBibcARl3FGEzzkWQupOW7wXRT1jTp4n55GIF3I-WmrxUR3PEFhedE-55n6GPzpqbLtxrftfL7sffIwsfBV5SLs-3oxWIgCQx3n6Og8FeCn8HLyb83gnv8MY73frwM56BM-D3ChuZLFiL22KxT36f1zca8szSuWv-DN1SWFKIfaMEO-pMRqoDLhN5WxegVZX9z1YmeqYoN0q75bSS0zR9PspVuVwSUFKniYt8VsiDW_oXEea6hTsFW4horn9mxzb4uzq2n1Cr2LTZEAAhIL4LH28jJXIFMPjQawX1rwZQu9rk96sLoyc3G7qW9XUJ45Vmx3k2XjR6QPKfFeLufy0InCk3Ct7qV40v1YFdViV9UhS_i5v2YNxaWScIeWs-IvHPZ2IIrgm2XhqIMJXDV0fnYT4AVi-9Xpfb2kBWA8TZN6EsfXdGGZ9M8nF3ncp9ASF1fsWVhw-hoMHvdSCRySFEnBQmA8-cl_CDMVuqMLwrtZE1yodbcPeHo5l7TzhIakUtpfyyDWyK9QgN2Zx2hUD8sC30L0XM6JW8mV_ar-l0C1jXYd4bxzJIl7hBdGeUoyBYOOSs_clkMM70MaWZ2OmxHuI5cwGxerViUajBjN0dE_C3WwLTKgrxfrh6nTm9XjLQamkAHQDk4qILxupJasH_RAmq5i47iBIEgIf006v4l4bokZKoCBAcHQmiV662UuhOOCJJjEWiXSVrgRZYcOxhOqrCrV7qtsLV12gOFVX8o-97MxB1qAZ35O5nyDYJUxwwURXykds4dwgBQlxfZUfZtz6n_GkDXKD9VH8KfdGylwP6vaWzotsGHwxQEAlbCqidXahCKmLrutW8b1Cb98NzYMfliHv7PaDS1xFAoyCG-S1bEalGqzftuyoQGglfriWai1HS2Qbwt--PBomfIqR7zRS6rz87a-Mj00XHckOBfp9v9uymoqCYUc-LY8F6VUh-1TphHQXp0-xoUD8MIpUDOhfvxGs5Zbn2eVGAs3A0Sjab8hHp7OXW7d1Rj0D1tNfJ4yzp-CXiDWhaFRYbnHNQJ7HNUtMJFL-LSYc2XrX-B7YShcdwXg7J4PrVoi0F3PInzzyjF9jkiFd2-bM-aixk6oqiUYNTcZD9nI4JrqVIptER4wSMwa2nj21dX8HrcvDNRfFicHemfzbUmAur8fmF-RiP1oj77qsaZayc9aBmEws0V0bIaqk1v-FKmZmrhfzklzwC5xOyUt1K4xDUa1AzOukgJ7yD0jHgs3xa0wKCeyITB1PAVIXNGBxRZh69IWh-U-mNA-EHcZ5YfpujxsIZzRlnNxC4suxbODINASxIVJJ24WySVJ_vJAuPEliF
[LogicallyAbstractScenarioUseCasePlant_UML.uml](/uploads/5c4313f19d46cd10514ca786c566aa9c/LogicallyAbstractScenarioUseCasePlant_UML.uml)
![LogicallyAbstractScenarioUseCasePlant_UML](/uploads/7318619d1bcbbc649146d6f757cd9d18/LogicallyAbstractScenarioUseCasePlant_UML.png)
![Abstraction](/uploads/c92f11598021c35d39ab23a1a4a1ea5f/Abstraction.png)
![ParmaterValueAbstractions](/uploads/843d2aa1697430b8929114a83ef33137/ParmaterValueAbstractions.png)
## Ask your question
Can the Usage and Pragmatics group consider this use case?>2.1Richard HeidtmanRichard Heidtman2021-03-01https://code.asam.net/simulation/openscenario/2.x/-/issues/938TSC Request: Investigate if the "EBNF" can be normative2024-03-07T09:19:57ZFlorian WALLERER (AVENYR GmbH)florian.wallerer@avenyr.deTSC Request: Investigate if the "EBNF" can be normativeWhen the TSC during the Soring 2024 meeting approved the release of OpenSCENARIO DSL 2.1.0, the requested the next project to check if the "EBNF" can be normative. As a possible user is expecting that also the downloadable EBNF file is n...When the TSC during the Soring 2024 meeting approved the release of OpenSCENARIO DSL 2.1.0, the requested the next project to check if the "EBNF" can be normative. As a possible user is expecting that also the downloadable EBNF file is normative not only the grammar in the specification
First step:
Investigate what needs do be done to make it normative>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/883using 'only' to extend a method when there is no prior definition2024-01-17T14:09:02ZRonen HADAR (Foretellix Ltd)using 'only' to extend a method when there is no prior definitionIn section Overriding methods it is stated as follows:
It is not an error if a method definition contains an `only` qualifier and there is no existing method to be overridden.
We want to use explicit overriding methods in order to prote...In section Overriding methods it is stated as follows:
It is not an error if a method definition contains an `only` qualifier and there is no existing method to be overridden.
We want to use explicit overriding methods in order to protect the users from typos.
It is obvious that a user that explicitly used 'only' want to override an existing method and therefore an error must be issued if the method was not previously declared (The previous declaration can be with or without implementation).>2.1Ronen HADAR (Foretellix Ltd)Ronen HADAR (Foretellix Ltd)https://code.asam.net/simulation/openscenario/2.x/-/issues/875How to deprecate outdated features.2023-12-14T10:19:54ZGhost UserHow to deprecate outdated features.After completing modifications to existing features, even if they don't disrupt backward compatibility, it is important to clearly document the new coding methods and identify any features that might be removed in future releases.After completing modifications to existing features, even if they don't disrupt backward compatibility, it is important to clearly document the new coding methods and identify any features that might be removed in future releases.>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/874Ability to use elapsed-expression and event-reference with bool-expression2023-12-13T16:18:02ZNajumun HIDHAYATHULLA (MathWorks)Ability to use elapsed-expression and event-reference with bool-expressionIn a scenario we can have a start and end trigger / condition. And that will be exported as a [event-specification](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/language_syntax.html#_events) to ...In a scenario we can have a start and end trigger / condition. And that will be exported as a [event-specification](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/language_syntax.html#_events) to OpenSCENARIO 2.0. The issue is that we cannot have elapsed-expression and event-reference with other type of expressions such as bool-expression.
For example, `elapsed(5s) or (white.time_to_collision(rock01) <= 0s)`
Currently OSC2 grammar doesn't support the above given example and resulting in syntax validation error. Hence, proposing to update the OSC2 grammar to support the above given example.>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/814Add evaluate/rule constriant for test criteria evaluation2023-11-20T10:08:45ZMax BAUER (Robert Bosch GmbH)Add evaluate/rule constriant for test criteria evaluationThere is a strong need from our users to do online evaluations of scenarios. A very simplified example may be the following:
```
scenario long_duration_run:
ego_vehicle: vehicle
do ego_vehicle.drive() with:
evaluate(ego_veh...There is a strong need from our users to do online evaluations of scenarios. A very simplified example may be the following:
```
scenario long_duration_run:
ego_vehicle: vehicle
do ego_vehicle.drive() with:
evaluate(ego_vehicle.speed > 10 kmh && ego_vehicle.speed < 10 kmh)
```
Here, the keep statement can not be used, since it is **not about trace rejection** (We definitely want to have the trace):
"Trace acceptance is not related to passing or failing tests. If an ASAM OpenSCENARIO model does not accept a trace, it means that the behavior is outside the scope of the ASAM OpenSCENARIO model. Test criteria can only be evaluated for accepted traces, meaning, if the behaviors are within the scope of the ASAM OpenSCENARIO model." https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/Semantics.html#sec-lc-semantics-semantic-foundations
One could use the `record` statement, however it is not always practicable.
Therefore we suggest to add the `evaluate` constraint to measure if test criteria are met:
```
ego_vehicle.drive() with:
evaluate(ego_vehicle.speed > 10 kmh)
```
Other suggestions for naming: rule/test_criteria/evaluation/...https://code.asam.net/simulation/openscenario/2.x/-/issues/813Lists of list2023-11-02T14:15:20ZMax BAUER (Robert Bosch GmbH)Lists of listIn the standard, lists of lists are prohibited:
"The list’s element type can be any type, except another list."
https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/types.html#_lists
Is this by accide...In the standard, lists of lists are prohibited:
"The list’s element type can be any type, except another list."
https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/types.html#_lists
Is this by accident? Cant this be enabled?https://code.asam.net/simulation/openscenario/2.x/-/issues/812Allow trailing commas2024-03-21T13:24:52ZMax BAUER (Robert Bosch GmbH)Allow trailing commasSome user requested that we allow trailing commas for better usability:
Some simple example with a comma after the last element:
```
my_list: list of str = [ "Pls",
"allow",
"comma",
...Some user requested that we allow trailing commas for better usability:
Some simple example with a comma after the last element:
```
my_list: list of str = [ "Pls",
"allow",
"comma",
"here ->", ]
```>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/809Floating point predicates for standard operations.2023-11-09T10:31:01ZGhost UserFloating point predicates for standard operations.Based on the discussion of https://code.asam.net/simulation/openscenario/2.x/-/merge_requests/484 OSC2 shall be extended with floating point predicates.
In particular predicates that check for "nan" or "inf" values.Based on the discussion of https://code.asam.net/simulation/openscenario/2.x/-/merge_requests/484 OSC2 shall be extended with floating point predicates.
In particular predicates that check for "nan" or "inf" values.>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/808Clarify how "inf" and "nan" shall be used with units2023-12-07T13:00:53ZGhost UserClarify how "inf" and "nan" shall be used with unitsBased on the discussion of https://code.asam.net/simulation/openscenario/2.x/-/merge_requests/484 there are two possible solutions here
1. one option is to separate them with space, i.e. `inf kph`
2. Another option is to put the units i...Based on the discussion of https://code.asam.net/simulation/openscenario/2.x/-/merge_requests/484 there are two possible solutions here
1. one option is to separate them with space, i.e. `inf kph`
2. Another option is to put the units inside bars, i.e. `inf|kph|`
An example and explicit explanation in the manual of this shall be prepared.>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/803Usage of behavior-with-declaration with temporal operators2023-12-07T13:01:00ZRolf MAGNUS (Akkodis)Usage of behavior-with-declaration with temporal operatorsThe OSC2 grammar definition allows `composition` to have a `behavior-with-declaration`, which can contain constraint declarations, modifier applications and until-directives.
However, chapter 7.3.13 only talks about passing parameters to...The OSC2 grammar definition allows `composition` to have a `behavior-with-declaration`, which can contain constraint declarations, modifier applications and until-directives.
However, chapter 7.3.13 only talks about passing parameters to composition operators similar to methods to constrain them, but nothing about using keep, let alone modifiers or until directives.
So are constraints, modifiers and until allowed in this place? If yes, we should describe what to use them for and how to do so. If not, we should change the grammar so these things are not considered syntactically correct.>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/801Violation of backward compatibility2023-12-21T09:00:32ZGhost UserViolation of backward compatibilityAny new type, enum, method, actor introduction can potentially vary backward compatibility of OSC2.
Potentially this problem can be solved by introduction of namespaces.
This shall be discussed in detail with language experts.Any new type, enum, method, actor introduction can potentially vary backward compatibility of OSC2.
Potentially this problem can be solved by introduction of namespaces.
This shall be discussed in detail with language experts.1.3 & 2.12023-08-31https://code.asam.net/simulation/openscenario/2.x/-/issues/779When do fields have reference semantics and when do they have value semantics?2023-12-07T12:23:54ZGhost UserWhen do fields have reference semantics and when do they have value semantics?[According to the standard](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/types.html#sec-lc-compound-types), actors, structs, actions, and scenarios are structured types. Furthermore,
> Fields re...[According to the standard](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/types.html#sec-lc-compound-types), actors, structs, actions, and scenarios are structured types. Furthermore,
> Fields represent data members inside structured types. Each field has a defined type. When instantiating a structured type, each field holds an instance of its respective type. A field can be defined as a parameter or a variable. Methods describe and implement the behavior of an object, which is an instantiation of a class. Fields, methods, and events are named and must have a unique name within the type.
Hence, if a scenario type has two fields of type vehicle, then the scenario instance (["the scenario that is executed"](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/conceptual-overview/key_terms.html#sec-global-terminology-scenario_instance)) holds two vehicle instances, and two vehicles exist inside the simulation. These are not references to a single vehicle.
However, many structured types within the domain model _refer_ to actors, instead of instantiating them. For example, the associated actor of actions or scenarios is an implicit field:
>This actor is called the associated actor and can be interpreted as the actor performing the behavior described in the scenario. However, within a scenario, the actor field and other parameter fields can be used in the same way.
Other examples are the 'reference: physical_object' field of 'action vehicle.change_lane', or the 'bm_engine: bm_engine' field of 'struct behavioral model' (a comment in standard.osc names it a "reference to the "behavioral model engine.""
As the section [Relational operators over non-numeric expressions](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/expressions_main.html#_relational_operators_over_non_numeric_expressions) indicates, names of parameters of structured types behave as references inside of expressions.
1. When are structured types instantiated?
A possible interpretation is that the scenario instance and, recursively, its structured type fields are instances. Furthermore, the global parameters of structured types instantiate these structured types.
2. When are names of structured types references?
A possible interpretation is that any behavior invocation and method call binds the names as references to the instances, but do not instantiate any structured types. This would conflict with 'bm_engine' being a reference as mentioned above, but this comment may use the word reference outside of the language scope anyway. Additionally, any names of structured types inside expressions are references.
This should probably be clarified by the standard. Do my interpretations make sense? Is this exhaustive, or are there other places where structured types occur?>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/757OverrideGearAction update (from OverrideControllerValueAction)2023-12-07T12:27:31ZMirko BULAJA (AVL-AST d.o.o.)OverrideGearAction update (from OverrideControllerValueAction)Manual and automatic gear support in the `OverrideGearAction`.
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/OverrideGearAction.htmlManual and automatic gear support in the `OverrideGearAction`.
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/OverrideGearAction.html>2.1Nicolas OCHOA LLERAS (DENSO Automotive)Nicolas OCHOA LLERAS (DENSO Automotive)2023-03-16https://code.asam.net/simulation/openscenario/2.x/-/issues/755Basic physical types2024-03-21T13:39:41ZRolf MAGNUS (Akkodis)Basic physical types[7.3.1](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/types.html#sec-lc-physical-types) Says that the 8 types
mass, length, time, angle, temperature, luminous_intensity, electrical_current and a...[7.3.1](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/types.html#sec-lc-physical-types) Says that the 8 types
mass, length, time, angle, temperature, luminous_intensity, electrical_current and amount_of_substance are "basic physical types" and that: "Other types and units (like speed, angular_rate, pressure, and illuminance, among others) are defined in the domain model."
However, the basic physical types are also defined in the domain model and in standard.osc, so are they supposed to be predefined in the language or are they part of the domain model and thus need to be explicitly defined (e.g. by importing osc.standard) to have them available?>2.12023-08-31https://code.asam.net/simulation/openscenario/2.x/-/issues/741SimulationTimeCondition is missing in the migration guide2023-12-07T12:28:53ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deSimulationTimeCondition is missing in the migration guidehttps://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/migration/mg_missing_osc1_elements.html#_simulationtimeconditionhttps://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/migration/mg_missing_osc1_elements.html#_simulationtimecondition>2.1Gil AMID (Foretellix Ltd)Gil AMID (Foretellix Ltd)2023-04-06https://code.asam.net/simulation/openscenario/2.x/-/issues/720Sub-scenarios and actors2023-12-07T13:00:25ZRolf MAGNUS (Akkodis)Sub-scenarios and actorsWhat happens if a scenario that contains unconstrained actors is invoked by another scenario? How is the actor created?
```
scenario my_scenario:
my_car: vehicle
do my_car.drive()
scenario main:
main_car: vehicle
other_c...What happens if a scenario that contains unconstrained actors is invoked by another scenario? How is the actor created?
```
scenario my_scenario:
my_car: vehicle
do my_car.drive()
scenario main:
main_car: vehicle
other_car: vehicle
do serial:
main_car.drive()
my_scenario()
```
I can see multiple possibilities:
- my_car is created when the main scenario starts, but has no directions until my_scenario is executed
- my_car is created dynamically as a new vehicle during execution, when my_scenario starts and vanishes when that sub-scenario has finished
- one of the existing main scenario vehicles is chosen at random
- an error is raised, because the scenario is using a car that doesn't exist>2.12023-07-31https://code.asam.net/simulation/openscenario/2.x/-/issues/718Behavior invocation and arguments2023-12-07T12:50:33ZRolf MAGNUS (Akkodis)Behavior invocation and argumentsThe LRM says that the argument list of a behavior invocation can make use of positional or named arguments. Allowing positional arguments imposes a lot of implications that I'm not sure everyone is aware of.
- For the domain model, that ...The LRM says that the argument list of a behavior invocation can make use of positional or named arguments. Allowing positional arguments imposes a lot of implications that I'm not sure everyone is aware of.
- For the domain model, that means that the order of the parameters of all actions is important, and care must be taken that in newer versions of the domain model, the parameters stay in the same order, because otherwise that may break existing scenarios.
- standard.osc must be checked for all behavior parameters if they are in the same order as in the standard.
- Currently, it is not defined what happens to the order of parameters on inheritance and extension and where the predefined `actor` and `duration` fields go.>2.1Rolf MAGNUS (Akkodis)Rolf MAGNUS (Akkodis)2023-07-31https://code.asam.net/simulation/openscenario/2.x/-/issues/704Figure illustration contains code with syntax errors2023-12-07T12:50:47ZPavel SHUMEJKO (Siemens)Figure illustration contains code with syntax errors[7.6.2.2 Scenario fields and bindings: Figure 9, An illustration of an ASAM OpenSCENARIO scenario execution state showing scenario instances and field bindings](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/languag...[7.6.2.2 Scenario fields and bindings: Figure 9, An illustration of an ASAM OpenSCENARIO scenario execution state showing scenario instances and field bindings](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/Semantics.html#sec-lc-semantics-scenario-fields-and-bindings), contains syntax errors in the do-directive of top.main. For example, the label of the do-directive is assigned with an assignment operator instead of a colon. Further, the behavior-with-declaration is missing a colon, and the constraint declarations use assigments instead of keep-constraint-declarations.
![example](/uploads/eb1508c19b176e1709d8fb85d87066ae/example.PNG)>2.12023-06-30https://code.asam.net/simulation/openscenario/2.x/-/issues/703Implicit conversion in physical types2023-12-07T12:50:53ZPavel SHUMEJKO (Siemens)Implicit conversion in physical typesIn [7.4.2.3 Arithmetic operators](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/expressions_main.html#sec-lc-operators-arithmetic-numeric-conversions) is stated that "Physical types are not conve...In [7.4.2.3 Arithmetic operators](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/expressions_main.html#sec-lc-operators-arithmetic-numeric-conversions) is stated that "Physical types are not converted."
Should an expression such as:
`5m / 2`
be allowed? In other words, should there be an implicit conversion from numerical types to a dimensionless physical unit? Such information is lacking in the standard.>2.12023-06-30