Simulation issueshttps://code.asam.net/groups/simulation/-/issues2024-03-21T13:27:28Zhttps://code.asam.net/simulation/openscenario/2.x/-/issues/8007.2 EBNF Grammar base2024-03-21T13:27:28ZReinhard KATZMANN (DXC Luxoft)7.2 EBNF Grammar baseThere are many syntax variants for EBNF available.
EBNF was choosen as grammar base. The base EBNF variant used here is not known (it's not ISO, W3C, Python or others I checked).
While the intent for the OSC standard on restrictions i...There are many syntax variants for EBNF available.
EBNF was choosen as grammar base. The base EBNF variant used here is not known (it's not ISO, W3C, Python or others I checked).
While the intent for the OSC standard on restrictions is clear, the grammar syntax needs to be defined in adequate detail to be able to understand the grammer. I have not found a complete grammar reference in the documentation (chapter 7.2).
Several tools can be used to create parsers automatically from EBNF grammar (f.e. antlr4, EBNF Studio, lark). For a start it's helpful to provide a way for checking grammar for generation to be able to parse existing examples and have a syntactically checker on own OSC2 code.
It's not a trivial task to create a parser. To provide a way to either transform the existing grammer to ISO EBNF grammar, to provide a expression file for such a transformation, to provide instructions or reference how to create parser is essential (I have found [clojure-grammar-based EBNF parser](https://mdkrajnak.github.io/ebnftest/))>2.1Reinhard KATZMANN (DXC Luxoft)Reinhard KATZMANN (DXC Luxoft)https://code.asam.net/simulation/openscenario/2.x/-/issues/796Description of applicable use cases2023-12-07T12:35:50ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deDescription of applicable use casesThe TSC in July ´23 requested from the project team to provide a clear description of applicable use-cases in the User Guide for the next release.The TSC in July ´23 requested from the project team to provide a clear description of applicable use-cases in the User Guide for the next release.>2.12023-12-31https://code.asam.net/simulation/openscenario/2.x/-/issues/794Usage of `speed` / `change_speed`2023-07-07T15:26:34ZBenjamin ENGEL (ASAM)benjamin.engel@asam.netUsage of `speed` / `change_speed`_Question submitted via Email to @engelben on 07.07.2023 by K&S Projektmanagement GmbH_
In OSC2 there are 2 modifiers to determine the speed of an actor (e.g. a `vehicle`):
```
speed ()
change_speed ()
```
Both seem to do the sam..._Question submitted via Email to @engelben on 07.07.2023 by K&S Projektmanagement GmbH_
In OSC2 there are 2 modifiers to determine the speed of an actor (e.g. a `vehicle`):
```
speed ()
change_speed ()
```
Both seem to do the same thing (excerpts from the OSC2 spec below).
```
speed(speed: speed
[, direction: lon_lat]
[, <standard-movement-parameters>])
```
vs
```
change_speed(speed: speed
[, <standard-movement-parameters>])
```
Is there a difference or when can/should one use the modifiers in a scenario?https://code.asam.net/simulation/openscenario/1.x/-/issues/572How would we migrate this very simple scenario?2023-07-10T07:08:00ZAndreas HEGE (RA Consulting GmbH)How would we migrate this very simple scenario?#### Describe the problem
Trying to go forward with migration I want to introduce a small exampe from the OSC standard to ask questions about the intended behavior.
My specific question is about the default controller that is part of th...#### Describe the problem
Trying to go forward with migration I want to introduce a small exampe from the OSC standard to ask questions about the intended behavior.
My specific question is about the default controller that is part of the OSC 1.x standard and if there is anything like this in OSC 2.0. Or at least. Is there any default behavior defined which help authors and simulator providers to have the same idea about what happens in a very small sceanrio.
#### Describe your research
Took an example from OSC 2.0 standard:
[OSC 2.0 Writing reusable sceanrios, code 3](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/user-guide/writing_reusable_scenarios.html):
```
scenario my_other_scenario:
do parallel:
init: car1.drive() with: # starts at t=0
speed(speed: 40kph, at: start)
a1: car1.drive() with: # further initial conditions for car1. This affects the same initial drive
lateral(speed: 2kph, at:start)
```
#### Ask your question
I've adapted the example above to the following. I hope it is still a valid OSC 2.0 scenario:
My question is: How would we migrate this very simple scenario?
```
scenario my_other_scenario:
do parallel:
p1: car1.drive(duration: 40s) with: # car 1: starts at t=0 drive 48 seconds
speed(speed: 40kph, at: start)
p2: car1.drive(duration: 20s) with: # car 1: starts at t=0 drive 20 seconds
lateral(speed: 2kph, at:start)
p3: car2.drive(duration: 30s) with: # car 2: starts at t=0 drive 30 seconds
speed(speed: 20kph, at: start)
```
Here are my questions and I give you an interpretation how OSC 1.0 would control behavior
When does the scenario finish?
OSC 1.x: Never or when the stop trigger of the enclosing storyboard fires.
OSC 2.0: After 40 seconds?
What is the (longitudinal) speed of car2 after 30 seconds?
OSC 1.x: After 30 seconds the longitudinal default controller takes over and keeps the speed until the end of the scenario. (20kph)
OSC 2.0: ?
What is the (lateral) behavior of car2?
OSC 1.x: The lateral speed of car2 has never been never addressed. The lateral default controller will keep the lane from the start.
OSC 2.0: ?
What is the (longitudinal) speed of car1 after 40 seconds?
OSC 1.x: After 40 seconds the longitudinal default controller takes over and keeps the speed until the end of the scenario. (40kph)
OSC 2.0: ?
What is the (lateral) behavior of car1 after 20 seconds?
OSC 1.x: After 20 seconds the lateral default controller takes over and keeps the current lane.
OSC 2.0: ?
In any way: Please give an idea of the behavior or confirm there is no default behavior and we have to make it explicit. We are moving forward, when we say that there is no default behavior.
In the case there is no default behavior, we have to make the default behavior explicit like:
```
scenario my_other_scenario:
do_serial:
do parallel:
p1: car1.drive(duration: 20s) with: # t=0 the first 20 second, after that the next serial block starts (at 20s)
speed(speed: 40kph, at: start)
p2: car1.drive(duration: 20s) with:
lateral(speed: 2kph, at:start)
p3: car2.drive(duration: 20s) with:
lateral(speed: 20kph, at:start)
p4: car2.drive(duration: 20s) with:
keep_lane()
do parallel:
p1: car1.drive(duration: 10s) with: # t=20s the next 10 seconds, after that the next serial block starts (at 30s)
speed(speed: 40kph)
p2: car1.drive(duration: 10s) with: # car1 now uses explicitly the lateral default behavior from OSC 1.x
keep_lane()
p3: car2.drive(duration: 10s) with:
lateral(speed: 20kph)
p4: car2.drive(duration: 20s) with:
keep_lane()
do parallel:
p1: car1.drive(duration: 10s) with: # t=30s the next 10 seconds, after that the next serial block starts (at 40s)
speed(speed: 40kph)
p2: car1.drive(duration: 10s) with: # car1 now uses explicitly the lateral default behavior from OSC 1.x
keep_lane()
p3: car2.drive(duration: 10s) with: # car2 now uses explicitly the longitudinal default behavior from OSC 1.x
keep_speed()
p4: car2.drive(duration: 10s) with:
keep_lane()
do parallel: # t=40s After 40 seconds the drive just should continue endlessly.
p1: car1.drive() with: # car1 now uses explicitly the longitudinal default behavior from OSC 1.x
keep_speed()
p2: car1.drive() with: # car1 now uses explicitly the lateral default behavior from OSC 1.x
keep_lane()
p3: car2.drive() with: # car2 now uses explicitly the longitudinal default behavior from OSC 1.x
keep_speed()
p4: car2.drive() with: # car2 now uses explicitly the lateral default behavior from OSC 1.x
keep_lane()
```
I am not such familiar with OSC 2.0 and I hope made not too much wrong in the example above. But my question is:
Is that the way we would migrate this very simple example?
Surely it is not automatable and surely we do not look at side effects with events. We have to take the default behavior of OSC 1.x into account while reengineering.
What's the behavior when parallel actions do not exactly have the same duration?
By the way: I took a systematic approach here (not an automated): Slice the parallel actions with different durations into serial blocks. Fill the holes with explicit default behavior from 1.x (Here comes the knowlegde of someone who does reengineering). Adapt the ending time from OSC 1.x (endless).
In any case, when we use parallel or serial combination of actions it must be defined when the actions are ending.
In a serial execution an action only starts after the predecessor action has ended. Or never, when the predecessor does not end.
When forking in a parallel execution the execution joins when every single parallel action has ended or never, when one of the actions never ends. That's what I assume on OSC 2.0
(Alternatively: a parallel excution could also end when the first fastest has ended. That's a race condition. But this depends on your definition)
Probably an OSC 2.0 expert give us a hint here.https://code.asam.net/simulation/openscenario/openscenario-migration/-/issues/8Add migration guide to represent OSC1.x 'delay' in OSC2.02023-07-13T10:21:39ZNajumun HIDHAYATHULLA (MathWorks)Add migration guide to represent OSC1.x 'delay' in OSC2.01.3 & 2.1Najumun HIDHAYATHULLA (MathWorks)Najumun HIDHAYATHULLA (MathWorks)https://code.asam.net/simulation/openscenario/2.x/-/issues/788Add temporal modification clauses to the event-condition to support 'delay'2023-12-07T13:01:03ZNajumun HIDHAYATHULLA (MathWorks)Add temporal modification clauses to the event-condition to support 'delay'In OSC1.x, there's a 'delay' attribute for [condition](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/Condition.html) and we don't have any direct mapping to this in OSC2.x.
...In OSC1.x, there's a 'delay' attribute for [condition](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/Condition.html) and we don't have any direct mapping to this in OSC2.x.
Hence, need to add a temporal modification similar to [fall-expression](https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/language-reference/language_syntax.html#_events)>2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/787keep_time_headway inconsistency between plantuml and standard.osc2023-12-15T09:27:43ZNicolas OCHOA LLERAS (DENSO Automotive)keep_time_headway inconsistency between plantuml and standard.osc
@rolf.magnus I just noticed **standard.osc** does not have the same definition as the plantuml for this action
![image](/uploads/9e452af76a868b78cab18cddadb340d3/image.png)
![image](/uploads/db63929a25c47170ded65c5d2806238b/image.png)...
@rolf.magnus I just noticed **standard.osc** does not have the same definition as the plantuml for this action
![image](/uploads/9e452af76a868b78cab18cddadb340d3/image.png)
![image](/uploads/db63929a25c47170ded65c5d2806238b/image.png)
1. standard.osc has an extra argument (direction). But I think "headway" would always assume the actor is trailing the reference. Therefore, I assume the plantuml is correct
2. standard.osc has the comments from a different action. Therefore, again I assume the plantuml is correct.
![image](/uploads/6074f9b9f39e82e616922a0bb93c4a13/image.png)>2.1Nicolas OCHOA LLERAS (DENSO Automotive)Nicolas OCHOA LLERAS (DENSO Automotive)https://code.asam.net/simulation/openscenario/openscenario-migration/-/issues/7Support for 'continuous' property in OSC2.0 Actions2023-07-13T15:05:52ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deSupport for 'continuous' property in OSC2.0 ActionsFor RelativeTargetSpeed Action, LongitudinalDistance Action and LateralDistance Action, we have a continuous property in OSC1.x. There is no equivalent for the same in OSC2.0 DM.
Following workarounds has been considered for OSC2.0. Ple...For RelativeTargetSpeed Action, LongitudinalDistance Action and LateralDistance Action, we have a continuous property in OSC1.x. There is no equivalent for the same in OSC2.0 DM.
Following workarounds has been considered for OSC2.0. Please confirm if this is the right approach. If not, it is recommended to include it in the OSC2.0 DM.
**RelativeTargetSpeed action**
![spd_cont](https://code.asam.net/simulation/openscenario/2.x/uploads/8147ebdcad3072ff1407ddce02b281ae/spd_cont.jpg)
**LongitudinalDistance action**
![lon_cont](https://code.asam.net/simulation/openscenario/2.x/uploads/7eb0ba9b77fa222da37881610113765e/lon_cont.png)1.3 & 2.1Emil KNABE (Volvo Cars)Emil KNABE (Volvo Cars)https://code.asam.net/simulation/openscenario/2.x/-/issues/785Dealing with default behavior from OSC12023-12-07T12:51:53ZMarcel LANGER (CARIAD SE)Dealing with default behavior from OSC1When migrating a concrete scenario from OSC1 to OSC2, the result should be a concrete OSC2 scenario.
This would require specifying all possible parameters according to https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/...When migrating a concrete scenario from OSC1 to OSC2, the result should be a concrete OSC2 scenario.
This would require specifying all possible parameters according to https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/conceptual-overview/scenario-abstraction.html#sec-global-terminology-logical_scenario
How would this be treated in the migration? How would "all possible parameters" be specified in the migration?
Example from OSC1: If I let a vehicle accelerate to 50 km/h with a SpeedAction, and define no further actions after that, it should (by default) continue traveling at this speed.
Is it defined somewhere what should happen in this situation in an OSC2 scenario?>2.1Marcel LANGER (CARIAD SE)Marcel LANGER (CARIAD SE)https://code.asam.net/simulation/openscenario/2.x/-/issues/784Migration of the optional SteadyState phase in OSC 1.X SyncronizeAction2023-12-07T12:51:43ZEmil KNABE (Volvo Cars)Migration of the optional SteadyState phase in OSC 1.X SyncronizeActionThe current migration example of the [SynchronizeAction](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/SynchronizeAction.html) was probably designed for OSC 1.0. From OSC v1...The current migration example of the [SynchronizeAction](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/SynchronizeAction.html) was probably designed for OSC 1.0. From OSC v1.1 it is possible to specify a final ["steady state"](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.1.1_Model_Documentation/modelDocumentation/index.html) phase for the controlled entity.
- Example 1: Reach final speed 10 meters from the destination.
- Example 2: Reach final speed 3 seconds before arrival to the destination.
Todo:
1. Identify or create a mapping of the 1.X steady state
2. Update the migration guideline and potentially the 2.X standard
(Clarification regarding steady state: Since the action entity can't be controlled during the (optional) final steady state, the synchronization might be slightly off in the end. I.e. the action entity might be either a bit early or late compared to the monitored entity which might change speed during this final phase. Conclusion being that steady state should be kept to a minimum needed.)>2.1https://code.asam.net/simulation/openscenario/1.x/-/issues/566DistributionDefinition limited to either Deterministic or Stochastic2023-04-25T12:25:39ZDennis CAPPENDIJK (Siemens)DistributionDefinition limited to either Deterministic or StochasticCurrently the [DistributionDefinition ](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/DistributionDefinition.html)node forces a choice between Deterministic or Stochastic. H...Currently the [DistributionDefinition ](https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/DistributionDefinition.html)node forces a choice between Deterministic or Stochastic. However I see no reason why an experiment can't have named parameters from either variation present.
What was the reasoning to keeping it exclusive to one type and would it be worth reconsidering that and allowing both types to be present?
F.e allowing this:
```xml
<OpenScenario>
<ParameterValueDistribution>
<Deterministic>
<DeterministicSingleParameterDistribution parameterName="ParameterA">
<DistributionRange stepWidth="2">
<Range lowerLimit="0" upperLimit="10"/>
</DistributionRange>
</DeterministicSingleParameterDistribution>
</Deterministic>
<Stochastic numberOfTestRuns="5" randomSeed="123">
<StochasticDistribution parameterName="ParameterB">
<ProbabilityDistributionSet>
<Element value="5" weight="10"/>
<Element value="10" weight="80"/>
<Element value="15" weight="10"/>
</ProbabilityDistributionSet>
</StochasticDistribution>
</Stochastic>
</ParameterValueDistribution>
</OpenScenario>
```https://code.asam.net/simulation/openscenario/2.x/-/issues/782Add range constraint and reference for clouds2023-04-20T13:27:39ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deAdd range constraint and reference for cloudsCurrently the range of the clouds (oin oktas) is only limited by the annotation. We could introduce an actual constraint for this struct to have a better automatic range checking.
Also there is not refernce given for the oktas. There is...Currently the range of the clouds (oin oktas) is only limited by the annotation. We could introduce an actual constraint for this struct to have a better automatic range checking.
Also there is not refernce given for the oktas. There is already one in OSI, which can be used: https://github.com/OpenSimulationInterface/open-simulation-interface/blob/master/osi_environment.protohttps://code.asam.net/simulation/openscenario/2.x/-/issues/780Integrate syntax checker into project and pipeline2024-02-08T16:42:07ZPhilip WINDECKER (AVENYR GmbH)Integrate syntax checker into project and pipelineRelated effort tracking issue: https://code.asam.net/internal/avenyr-asam/-/issues/228
Merge request: https://code.asam.net/simulation/openscenario/2.x/-/merge_requests/477
## Description
The idea is to integrate the available py-osc2 s...Related effort tracking issue: https://code.asam.net/internal/avenyr-asam/-/issues/228
Merge request: https://code.asam.net/simulation/openscenario/2.x/-/merge_requests/477
## Description
The idea is to integrate the available py-osc2 syntax checker into this project so that the pipeline checks (select) osc(2) files for their syntax.
The script shall also be usable locally to verify examples and such before pushing them to remote.>2.1Reinhard KATZMANN (DXC Luxoft)Reinhard KATZMANN (DXC Luxoft)https://code.asam.net/simulation/openscenario/openscenario-migration/-/issues/5DirectionalDimension support in 1.2 conditions2023-04-13T15:03:16ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deDirectionalDimension support in 1.2 conditionsDirectionalDimension enumeration and usage in AccelerationCondition, RelativeSpeedCondition and SpeedCondition.
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/DirectionalDim...DirectionalDimension enumeration and usage in AccelerationCondition, RelativeSpeedCondition and SpeedCondition.
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/DirectionalDimension.html1.3 & 2.1Mirko BULAJA (AVL-AST d.o.o.)Mirko BULAJA (AVL-AST d.o.o.)https://code.asam.net/simulation/openscenario/openscenario-migration/-/issues/3Enumeration cases for v1.2 ColorType should be present in the v2.0 color enum2023-04-06T14:07:42ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deEnumeration cases for v1.2 ColorType should be present in the v2.0 color enumOpenScenario v1.2 contains a ColorType enumeration:
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/ColorType.html
Similar enum is defined in OpenScenario v2.0:
https://www...OpenScenario v1.2 contains a ColorType enumeration:
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/ColorType.html
Similar enum is defined in OpenScenario v2.0:
https://www.asam.net/static_downloads/public/asam-openscenario/2.0.0/domain-model/entity.html#sec-trafficparticipant-enum-color
Not all colors from v1.2 are in the v2.0.1.3 & 2.1https://code.asam.net/simulation/openscenario/openscenario-migration/-/issues/2Entity roles are missing in the migration guide2023-04-06T13:44:19ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deEntity roles are missing in the migration guideWas introduced with OSC 1.2 for pedestrians and vehicles.
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/Role.htmlWas introduced with OSC 1.2 for pedestrians and vehicles.
https://www.asam.net/static_downloads/ASAM_OpenSCENARIO_V1.2.0_Model_Documentation/modelDocumentation/content/Role.html1.3 & 2.1https://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/1.x/-/issues/564Add documentation strings to XSD schema2023-10-11T06:54:32ZJakob KATHS (Vector Informatik GmbH)Add documentation strings to XSD schemaSimilar to OpenDRIVE, the xsd schema should include the already existing documentation strings for classes, attributes, etc, i.e. the documentation that is available in the html document. Once exported into the xsd, the strings are easie...Similar to OpenDRIVE, the xsd schema should include the already existing documentation strings for classes, attributes, etc, i.e. the documentation that is available in the html document. Once exported into the xsd, the strings are easier to use for tools that build upon the xsd schema, say editors, validation, etc. As all the content is there and an export already works for OpenDRIVE, this should be easy to achieve. Only pitfalls can be, that some documentation strings are duplicated and more or less useful in depending on their "location", e.g. Act as child of Story ("Defines the acts of the story.", which is relatively useless) vs. Act itself ("A container for maneuver groups. Can be executed several times depending on the user provided settings. New executions are only allowed to start when all contained maneuver groups are in the complete state.", which is much better).
An example for Condition Edge can look like this:
` <xsd:simpleType name="ConditionEdge">
<xsd:annotation>
<xsd:documentation>Edge types that can be used for conditions.</xsd:documentation>
</xsd:annotation>
<xsd:union>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="falling">
<xsd:annotation>
<xsd:documentation>A condition defined with a falling edge shall return true at discrete time t if its logical expression is false at discrete time t and its logical expression was true at discrete time t-ts, where ts is the simulation sampling time.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="none">
<xsd:annotation>
<xsd:documentation>A condition defined with a 'none' edge shall return true at discrete time t if its logical expression is true at discrete time t.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="rising">
<xsd:annotation>
<xsd:documentation>A condition defined with a rising edge shall return true at discrete time t if its logical expression is true at discrete time t and its logical expression was false at discrete time t-ts, where ts is the simulation sampling time.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
<xsd:enumeration value="risingOrFalling">
<xsd:annotation>
<xsd:documentation>A condition defined with a 'risingOrFalling' edge shall return true at discrete time t if its logical expression is true at discrete time t and its logical expression was false at discrete time t-ts OR if its logical expression is false at discrete time t and its logical expression was true at discrete time t-ts. ts is the simulation sampling time.</xsd:documentation>
</xsd:annotation>
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>
<xsd:simpleType>
<xsd:restriction base="parameter"/>
</xsd:simpleType>
</xsd:union>
</xsd:simpleType>`https://code.asam.net/simulation/openscenario/openscenario-migration/-/issues/1TimeToCollision2023-10-11T06:49:08ZAndreas RAUSCHERT (BMW Group)andreas.rb.rauschert@bmw.deTimeToCollisionThe definition for TimeToCollision is different across OSC1.x and OSC2.0. We need to ensure same meaning is conveyed for TimeToCollision.
OSC1.x - Time to collision is calculated as the distance divided by the relative speed.
OSC2.0 - ...The definition for TimeToCollision is different across OSC1.x and OSC2.0. We need to ensure same meaning is conveyed for TimeToCollision.
OSC1.x - Time to collision is calculated as the distance divided by the relative speed.
OSC2.0 - Time that is left until a possible collision between a traffic_participant and a reference physical_object takes place. (Here assumption is both the actors move with their current velocities)
Possible solution:
Either ensure it is defined the same across the standards or update the migration guideline with the possible approach.1.3 & 2.1https://code.asam.net/simulation/openscenario/2.x/-/issues/777norm pre-defined method(s)2023-04-03T12:11:44ZMeir OVADIA (Synopsys)norm pre-defined method(s)
There is a method called “norm” defined in structs position3d, velocity3d, and acceleration3d. I tried looking for information about this method, but I haven’t been able to find any in the LRM.
Based on my intuition, I guess it refers...
There is a method called “norm” defined in structs position3d, velocity3d, and acceleration3d. I tried looking for information about this method, but I haven’t been able to find any in the LRM.
Based on my intuition, I guess it refers to the normalized value of position, velocity, etc wherein we are supposed to calculate the unit vector, is that right? If not, what exactly is the purpose of these methods?