OpenSimulationInterface / open-simulation-interface

A generic interface for the environmental perception of automated driving functions in virtual scenarios.
Other
265 stars 124 forks source link

How is message validity defined, if rules are broken #782

Closed ClemensLinnhoff closed 2 months ago

ClemensLinnhoff commented 4 months ago

Describe the problem

In the proto files, rules are defined for certain fields. Let's take the following example: In the SensorData::FeatureData::LidarDetectionData::LidarDetection there is the following rule for the intensity field:

is_greater_than_or_equal_to: 0
is_less_than_or_equal_to: 100

Let's say the intensity is wrongly set to 150 in one LidarDetection.

Ask your question

What does this mean for the rest of the message? Can the other fields of the same LidarDetection still be used, e.g. the position? Or are all other LidarDetection also to be seen as invalid? Is maybe the entire LidarDetectionData invalid if one field does not comply? Or is the entire top-level message, i.e. SensorData, not to be used in such a case?

pmai commented 2 months ago

As usual, violating rules in a standard leads to unspecified behavior, unless a clear specification on error handling is given.

Hence an implementation may start WW3 - though laws and regulations might not allow one to do exactly that - or it may handle this very robustly. The standard does not say. Of course other mechanisms, like basic common sense or market pressures are likely to lead to implementations not going out of their way to be unhelpful.

It is also unlikely that we want to specify error handling here, because that tends to be a lot of painstaking work, with little impact, as implementors tend to do what they tend to do anyway, and the simplest approach is to just not violate rules.

Now that also might point to the fact that we should not have too strict rules, when they do not make sense.