qc-osi: rule definitions

[jdsika]

• are there any guidelines how to define rules in the quality checker framework?
• can we define our rules as e.g. reg. expressions?
• are there any todo's regarding the qc?

[pmai]

Current draft definition for mostly automatic rule mapping:

• Common prefix asam.net:osi:3.7.0:auto. (open question: do we try to keep track of the first version that the rule was introduced? If so we always need all past rulesets for the mapping, if not then this can be handled more independently).
• Message names downcased (with any definition nesting) separated by dots, e.g. ´movingobject.vehicleattributes.´
• The field the rule applies to, separated by underscore, e.g. number_wheels_
• Rule name, e.g. is_set with argument, if supplied, seperated by an underscore is_greater_than_or_equal_to_1
• If this leads to duplicate names, then an index starting with 1 is appended (with a leading underscore), in the textual order the rules appear in the file.

Full example:
asam.net:osi:3.7.0:auto.movingobject.vehicleattributes.number_wheels_is_greater_than_or_equal_to_1

[asadekasam]

@ijelec Please Add AVL insights here

[TimmRuppert]

As base for discussion I would like gather some potential check_if approaches:

osi_roadmarking.proto contains the longest 'check_if' rules while also showing the deepest encapsulation of such a rule (ruleset consists of 3 levels)

Naive way

Following the already suggested schema, appending all arguments would lead to

• asam.net:osi:3.7.0:auto.roadmarking.classification.type_check_if_this_type_is_greater_than_or_equal_to_2_else_do_check is_set

• asam.net:osi:3.7.0:auto.movingobject.vehiclelassification.trailer_id_check_if this_has_trailer_is_equal_to_true_else_do_check_is_set

This is ridiculous long but in comparison to:

• asam.net:osi:3.7.0:auto.movingobject.vehicleattributes.number_wheels_is_greater_than_or_equal_to_1
  not much worse.

Stripping some rule words

• Pro: Shorther

• Con:

  • Not significant easier to understand
  • Might break future stuff e.g. in case a check_if.. do_something_else would be introduced

• asam.net:osi:3.7.0:auto.roadmarking.classification.type_if_this_type_is_greater_than_or_equal_to_2_else_is_set

• asam.net:osi:3.7.0:auto.movingobject.vehiclelassification.trailer_id_if this_has_trailer_is_equal_to_true_else_is_set

I think I might need a bit of tutoring to fully understand the check_if rule. The rule includes an else, but logically it seems like the else part should happen if the first part is true, right?

In the trailer_id example, the intention seems to be to check whether has_trailer is set to true, and then trailer_id must also have a value. But with the else in the rule, I actually understand it the other way around:

check_if this.has_trailer is_equal_to true else do_check is_set

To me, this sounds more like the do_check is only executed if has_trailer is not true. That cannot be the intention, can someone please explain the idea behind the syntax to me? Maybe I'm just being a bit dense here.